Seiteninhalt Home / Know-How / DNS-Server mit Pi-Hole(R) und Unbound

DNS-Server als Werbe- und Trackingfilter mit Raspberry Pi und Pi-Hole® und Unbound

Obwohl es diesen Mini-Computer schon seit geraumer Zeit gibt, bin ich erst vor kurzem auf ihn aufmerksam geworden und bin über die Einsatzmöglichkeiten erstaunt.

Ich habe aktuell zwei "Projekte", einen "MP3-Server" für die Stereoanlage sowie einen eigenen lokalen DNS-Server. Hier geht es um den DNS-Server, primär als Filter gegen Werbung und Tracking im internen Netzwerk. Grundlage ist das Projekt "Pi-Hole®". Es gibt auch eine Dokumentation dazu.

Mein Heimnetzwerk läuft unter 192.168.178.x. Der Router, eine FritzBox 7560 als Standard-Gateway, auch als Zeitserver und als (weiterer) DNS-Server ist die 192.168.178.1.

Ich verwende hier einen Raspberry Pi 3B in dem originalen weiß/himbeerfarbenen Gehäuse und eine Micro-SD-Karte Sandisk Ultra 32GB (SDHC, UHS-1, Class 10) sowie das originale Raspberry-Pi-Netzteil in Weiß. Das ist eine ungefähre Investition von 65 Euro (Stand 01/2019).

Update: Zwischenzeitlich verwende ich einen Raspberry Pi 4B Rev. 1.1 mit 4 GB RAM mit einer Micro-SD-Karte Sandisk Extreme Pro 64 GB (SDXC, UHS-1, UHS Speed Class 3, Video Speed Class V30, Application Performance Class A2). Damit kann ich über USB 3 externe Festplatten anschließen und im Netzwerk freigeben und auch die höhere Geschwindigkeit der SD-Karte ist in einigen Situationen spürbar. Trotzdem ist noch immer ein lüfterloser Betrieb möglich, ohne dass das System überhitzt.

 

Vorbereitungen

  • Raspbian Stretch Lite Image downloaden (Hinweis: Die gesamte folgende Anleitung wurde für und mit Raspbian Stretch (Debian9) geschrieben. Sie funktioniert aber auch für Raspbian Buster (Debian 10), wenn Pi-Hole ab Version 4.3.1 verwendet wird und auch mit Raspberry Pi OS Bullseye (Debian 11) mit der von mir verwendeten Pi-Hole-Version 5.6.)
  • die heruntergeladene .zip-Datei entpacken und daraus eine .img-Datei erhalten
  • Die Micro-SD-Karte ggf. mit einem Adapter in PC bzw. das Lesegerät stecken
  • Das entpackte Image muss anschließend auf die SD-Karte geschrieben werden, damit daraus ein bootfähiger Datenträger wird. Dafür kann man unter Windows z.B. den Raspberry Pi Imager verwenden (Empfehlungen von Raspberry Pi für Windows). In dieser Software kann man zusätzlich im "Advanced Options menu" Einstellungen durchführen, die ansonsten etwas müham durchzuführen sind. Beispielsweise kann man hier bereits die SSH aktivieren (sehr sinnvoll!) oder auch den hostname bestimmen.
  • Die SD-Karte in den Pi stecken und den Pi an die Stromversorgung anschließen
  • Alternative 1: Auf der SD-Karte (noch im PC) auf der für den PC lesbaren Partition "boot", wo auch die Datei "config.txt" liegt, eine leere Datei "ssh" (ohne Dateiendung, ohne Inhalt) anlegen
  • Alternative 2: Einmalig TV/Monitor (via HDMI) und Tastatur (via USB) an den Pi anschließen aufgrund des im Originalzustands in Raspbian Stretch (aus Sicherheitsgründen) deaktivierten SSH-Zugangs
  • Den Pi als zukünftigen DNS-Server und damit ganz wichtigen Heimnetzwerk-Bestandteil mit einem Netzwerkkabel an den Router anschließen, nicht via WLAN!
  • Einloggen mit user:pi / password:raspberry (Achtung: engl. Tastatur, d.h. y und z sind vertauscht...)
  • In der Shell aufrufen: sudo raspi-config
  • (Dort im Menü unter "Interfacing Options" nun die SSH aktivieren)
  • Dort im Menü noch entsprechend dem Land lokalisieren, d.h. Sprache einstellen, Tastaturlayout und auch die richtige Zeitzone setzen sowie vorsorglich das "WLAN Country" richtig wählen
  • Unter "Advanced Options" das Filesystem expandieren (wird erst nach Neustart wirklich durchgeführt), d.h. von der Datenmenge des geschriebenen Image (siehe oben) auf die maximal verfügbare Größe der SD-Karte.
  • Neu starten mit sudo shutdown -r now
  • nun von einem Client aus per SSH auf den Pi zugreifen (unter Windows mit dem separaten kostenfreien Programm Putty oder unter Windows 10 in der Windows Power Shell) und wieder einloggen (Login siehe oben).
  • in der Shell erneut aufrufen: sudo raspi-config
  • Neu starten
  • System aktualisieren
    • sudo apt update
    • sudo apt upgrade
    • sudo apt dist-upgrade
  • Die Datei /boot/config.txt ändern mit sudo nano /boot/config.txt
  • in /boot/config.txt einfügen zum Deaktivieren von WLAN und Bluetooth, außerdem Untertakten zum Strom sparen und Wärme reduzieren:
    dtoverlay=pi3-disable-wifi
    dtoverlay=pi3-disable-bt
    arm_freq_min=500
    sdram_freq_min=200
    gpu_freq_min=100
    temp_limit=75
    never_over_voltage=1
  • Zeitserver definieren mit folgenden Einträgen in: sudo nano /etc/systemd/timesyncd.conf
    NTP=192.168.178.1
    FallbackNTP=0.de.pool.ntp.org 1.de.pool.ntp.org
  • Danach die folgenden Befehle ausführen, damit der NTP-Service (man kann auch einen anderen, evtl. schon vorhandenen NTP-Service verwenden wie z.B. chrony) aktiviert und aktualisiert wird:
    • sudo systemctl restart systemd-timesyncd.service
    • sudo systemctl status systemd-timesyncd.service
    • sudo systemctl enable systemd-timesyncd
    • sudo systemctl start systemd-timesyncd
    • sudo timedatectl set-ntp 1
    • timedatectl
  • Weitere Aktualisierungen und Einstellungen des Systems durchführen:
    • sudo apt install ca-certificates
    • sudo shutdown -r now
    • sudo apt autoremove
    • sudo apt autoclean

 

Installation und Einrichtung

  • Nun die Installation des Pi-Hole starten, dabei wird ein umfangreiches Installationsmenu durchlaufen (auch in der SSH):
    • sudo curl -sSL https://install.pi-hole.net | bash
  • Dort einstellen (man kann dieses Installationsmenü per SSH später neu aufrufen mit pihole -r):
    • Upstream DNS Provider Google (kann man später auch noch im Webinterface ändern)
    • Protokolle: IPV4, kein IPV6
    • Statische IP-Adresse: Vorschlag 192.168.178.2/24 und Gateway 192.168.178.1 annehmen
    • Admin-Interface installieren: Ja
    • Webserver lighttpd installieren (für das Admin-Interface): Ja
    • Log: Ja
    • Privacy Mode: Alles anzeigen
  • Um das Schreiben der Logs auf die SD-Karte und damit deren Belastung etwas zu reduzieren, verlängert man die Frequenz des Log-Schreibens von 1 (Standard) auf 60 Minuten mit
    sudo nano /etc/pihole/pihole-FTL.conf und dort ergänzen:
    DBINTERVAL=60
  • Das Admin-Interface im Browser auf einem der Clients aufrufen mit:
    http://pi.hole/admin oder mit http://192.168.178.2/admin mit dem Passwort wie vom Pi-Hole generiert.
  • Ergänzende Listen für Domains, die man unter Settings / Blocklists eintragen kann: firebog.net.
  • Unter Settings / DNS kann man die DNS-Server im Internet festlegen, an die DNS-Anfragen, die nicht geblockt werden, weitergeleitet werden sollen. Dabei kann man unter vorkonfigurierten Services auswählen oder auch (zwei) andere Server eintragen. Im Hinblick auf Datenschutz, Zensur und andere Faktoren habe ich ausgewählt:
  • Etwas weiter unten auf dieser Einstellungseite sollte man auch auf jeden Fall DNSSEC aktivieren.
  • Pi-Hole lässt sich auf neuere Versionen aktualisieren mit dem Shell-Kommando pihole -up (Neustart des Servers nötig!).
  • Die Web-Admin-Oberfläche des Pi-Hole kann man auch ohne Passwort betreiben. Dazu gibt man in der SSH ein: pihole -a -p und anschließend lässt man das geforderte neue Passwort leer.

Mit der bis hierhin beschriebenen Konfiguration hat man einen hervorragend funktionierenden Werbefilter, der zwischen 10% und 50% Traffic schon vor den Clients im Heimnetz filtert.

Wenn man noch einen Schritt weitergehen möchte, kann man (ebenfalls auf demselben Raspberry Pi) einen eigenen DNS-Server aufsetzen, den Pi-Hole zuerst anfragt und der erst wenn er keine Antwort kennt, externe DNS-Server abfragt. Dies erhöht die Sicherheit noch einmal einen Schritt, obwohl dadurch (vor allem anfangs) die Netzwerkabfragen etwas verlangsamt. Dieser weitere Schritt wird auch in einer speziellen Pi-Hole-Dokumentation auf Basis des DNS-Servers Unbound separat erklärt. Den DNS-Server Unbound kann man auch vor der Installation des Pi-Hole installieren.

Hier ebenfalls Schritt für Schritt erklärt:

 

Installation und Einrichtung von Unbound (für Debian 10 (Buster) mit Unbound 1.9.0 oder für Debian 11 (Bullseye) mit Unbound 1.13.1 oder höhere Versionen)

Auf Debian 9 wird die Version 1.6.0 von Unbound installiert, für die es ein vorgefertigtes Installationspaket gibt, die keine Verbindung mittels DNS over TLS zu externen DNS-Servern über Port 853 herstellen kann. Mit Version 1.9.0, die aber nur für Debian 10 vorliegt, kann dagegen DNS over TLS und damit eine verschlüsselte DNS-Übertragung verwendet werden.

  • Installation von Unbound (und des Sicherheitsframeworks AppArmor) starten mit sudo apt install unbound apparmor
  • Holen des aktuellen Root Key für die DNSSEC-Validierung mit sudo unbound-anchor
  • Aktuelle Datei "root.hints" (Liste der DNS Root Server, die die Domain "." bereitstellen. Die Liste wird ca. alle 6 Monate aktualisiert und die Datei ändert sich dabei in unregelmäßigen Abständen.) downloaden und installieren mit:
    • sudo wget -O /etc/unbound/root.hints https://www.internic.net/domain/named.root
    • sudo wget -O /var/lib/unbound/root.hints https://www.internic.net/domain/named.root
  • Die Datei /etc/unbound/unbound.conf.d/pi-hole.conf neu anlegen mit sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf und dort reinkopieren:
    server:
    chroot: ""
    # If no logfile is specified, syslog is used
    logfile: "/var/log/unbound.log"
    verbosity: 1
    log-time-ascii: yes
    log-queries: no

    # Port for Usage in Pi-Hole as 127.0.0.1#5353 - port 5353 is used by mDNS, for example Avahi inside Openmediavault, recommended is port 5335
    port: 5335

    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    root-hints: "/var/lib/unbound/root.hints"
    tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"

    # Trust glue only if it is within the servers authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # TTL bounds for cache
    cache-min-ttl: 3600
    cache-max-ttl: 86400

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes
    prefetch-key: yes

    # One thread should be sufficient, can be increased on beefy machines
    num-threads: 2

    # Number of slabs in the RRset cache. Slabs reduce lock contention by
    # threads. Must be set to a power of 2 close to num-threads
    msg-cache-slabs: 2
    rrset-cache-slabs: 2
    infra-cache-slabs: 2
    key-cache-slabs: 2

    # Cache Memory rrset should have double size as msg
    msg-cache-size: 50m
    rrset-cache-size: 100m

    # more outgoing connections
    # depends on number of cores: 1024/cores - 50
    outgoing-range: 450

    # Accelerate UDP with multithreading
    so-reuseport: yes

    # Ensure kernel buffer is large enough to not loose messages in traffic spikes (not used together with activated AppArmor)
    # so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

    access-control: 192.168.0.0/16 allow

    forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#one.one.one.one
    forward-addr: 1.0.0.1@853#one.one.one.one
    forward-addr: 9.9.9.11@853#dns11.quad9.net
    forward-addr: 8.8.8.8@853#dns.google
    forward-addr: 84.200.69.80@853#resolver1.dns.watch
    forward-addr: 84.200.70.40@853#resolver2.dns.watch
    forward-addr: 5.9.164.112@853#dns3.digitalcourage.de
    forward-addr: 9.9.9.9@853#dns.quad9.net
  • Danach die Datei abspeichern
  • Eine weitere neue Konfigurationsdatei anlegen mit
    sudo nano /etc/dnsmasq.d/99-edns.conf und dort den entsprechenden Parameter zu o.g. edns-buffer-size: 1232 hinterlegen als
    edns-packet-max=1232
  • Für die in der Datei /etc/unbound/unbound.conf.d/pi-hole.conf erwähnte Log-Datei /var/log/unbound.log muss noch der Besitzer und die Gruppe angepasst werden, damit keine Fehlermeldungen durch AppArmor entstehen, mit
    sudo chown unbound:unbound /var/log/unbound.log
  • Für AppArmor sollten wir noch weitere Anpassungen vornehmen mit Editieren der entsprechenden Datei mit
    sudo nano /etc/apparmor.d/local/usr.sbin.unbound und Ergänzen des folgenden Eintrags:
    /var/log/unbound.log rw,
  • In der übergeordneten Datei muss noch der include-Eintrag für /etc/apparmor.d/local/usr.sbin.unbound aktiv gesetzt werden mit
    sudo nano /etc/apparmor.d/usr.sbin.unbound und Entfernen des "#" vor dem Eintrag
    include <local/usr.sbin.unbound>
  • Auch in der Datei cmdline.txt in der Boot-Partition der SD-Karte fehlt noch ein Eintrag für AppArmor, damit der Service überhaupt vollständig starten kann und im System bekannt ist (Siehe dazu auch die Anleitung bei ArchLinux über AppArmor). Diesen Eintrag mit einem Texteditor an das Ende der einzigen Zeile in dieser Datei ergänzen:
    apparmor=1 lsm=landlock,lockdown,yama,integrity,apparmor,bpf
  • Danach AppArmor neu starten mit:
    sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.unbound
    sudo service apparmor restart
  • Nun Unbound starten und "aktivieren", sodass er auch bei einem Neustart des Raspberry Pi automatisch mit startet (den Service neu starten kann man mit
    sudo systemctl restart unbound.service):
    • Starten mit: sudo systemctl start unbound.service
    • "Aktivieren" mit: sudo systemctl enable unbound.service
  • Unbound-Status abfragen mit sudo systemctl status unbound.service
  • Nun Unbound einmal testen mit z.B. dig pi-hole.net @127.0.0.1 -p 5335
  • Als letztes muss man Unbound noch in Pi-Hole als (einzigen) DNS-Server eintragen unter "Custom 1 (IPV4)" als "127.0.0.1#5335"
  • Nun Deaktivieren des standardmäßig aktiven, und mit Unbound aber nun obsoleten DNS Cache Daemon systemd-resolved mit
    sudo systemctl disable systemd-resolved
  • Nun müssen wir auch noch (wenn Debian Bullseye bzw. 11 oder neuere Varianten laufen) den Eintrag für Unbound in der Systemdatei resolvconf.conf deaktivieren (siehe dazu auch die Pi-Hole-Unbound-Anleitung) mit
    sudo systemctl disable --now unbound-resolvconf.service
    sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf
    sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
    sudo systemctl restart unbound.service
  • Ebenfalls ist es möglich, falls im Netzwerk nicht benötigt, den mDNS-Service Avahi zu deaktivieren. mDNS bietet ähnliche Dienste wie NetBIOS und wird von manchen Geräten im lokalen Netzwerk evtl. verwendet. Bei mir ist das nicht der Fall (genauso wie niemand bei mir NetBIOS und WINS benötigt), sodass ich Avahi deaktiviere mit
    sudo systemctl disable avahi-daemon

Nun müsste alles laufen wie zuvor, nur dass (seit Aktivierung des Unbound) das erste Mal aufgerufene Seiten etwas länger benötigen, bis sie geladen werden. Dies ist ein gutes Zeichen dafür, dass Unbound arbeitet!

 

Im Router (hier FritzBox 7560, FritzOS 7.29) einstellen

Unter Heimnetz / Netzwerkeinstellungen / Weitere Einstellungen / IPV4-Einstellungen unter den DHCP-Adressbereichen die Adresse des Pi-Hole (hier 192.168.178.2) als lokaler DNS-Server eintragen. Damit verteilt das DHCP den lokalen DNS-Server automatisch mit im Netz und man muss nichts an den Clients einstellen!

 

WPAD konfigurieren

WPAD steht für Web Proxy Autodiscovery Protocol ist ein Protokoll, mit dem Web-Clients zu verwendende Web-Proxys innerhalb eines Computernetzwerkes automatisch finden können, indem eine Proxy autoconfiguration-Datei unter einer URL gespeichert wird. Dazu legt man eine Datei wpad.dat sowie proxy.pac (jeweils mit identischem Inhalt) an, um solche Client-Anfragen korrekt zu handhaben und um Missbrauch vorzubeugen.

Man sollte so vorgehen:

  • In der Datei /etc/hosts auf dem Pi-Hole-System entweder den vorhandenen Eintrag mit der Pi-Hole-IP ergänzen oder neu anlegen (Beispiel für eine FritzBox, die vorhandenen Anfragen dazu kann man im Query Log des Pi-Hole ersehen):
    192.168.178.2 wpad.fritz.box wpad.box wpad.com wpad.de wpad
    bzw. in der "Local DNS"-Konfiguration des Pihole ebenfalls so anlegen, dort allerdings mit Kommata trennen anstatt mit Leerzeichen
  • In der Datei /etc/lighttpd/external.conf auf dem Pi-Hole-System de folgenden Code einfügen:
    $HTTP["host"] =~ "wpad" {
    server.document-root = "/var/www/wpad/"
    mimetype.assign = (
    ".dat" => "application/x-ns-proxy-autoconfig",
    ".pac" => "application/x-ns-proxy-autoconfig"
    )}
    Damit leitet man jegliche Anfragen bzgl. *wpad* in dieses (neue) Verzeichnis des Pi-Hole-Webservers lighttpd weiter, wo auch noch die Datei wpad.dat und proxy.pac angelegt werden. Das Verzeichnis liegt nicht in der www-root des Webservers, sondern "daneben.
  • Nun das Verzeichnis /var/www/wpad/ anlegen und dessen Rechte entsprechend anpassen:
    sudo mkdir /var/www/wpad
    sudo chown -hR www-data:www-data /var/www/wpad
    sudo chmod 775 /var/www/wpad
  • Nun in diesem Verzeichnis die Datei wpad.dat anlegen und den Inhalt einschreiben:
    sudo nano /var/www/wpad/wpad.dat
  • Als Inhalt kommt da rein, dass kein Proxy vorhanden ist und Anfragen direkt beantwortet werden sollen (der Code ist an sich JavaScript): function FindProxyForURL(url, host) {return "DIRECT";}
  • Die Datei vorsorglich identisch nochmal kopieren als proxy.pac:
    sudo cp /var/www/wpad/wpad.dat /var/www/wpad/proxy.pac
  • Nun den Webserver neu starten:
    sudo service lighttpd restart
  • Das Ganze im Browser eines Clients testen mit dem Aufruf der Datei, die dann im Erfolgsfall gedownloadet wird:
    https://wpad.local/wpad.dat

So werden dann zahlreiche Anfragen im internen Netzwerk nach der wpad.dat nicht (erfolglos) nach außen geleitet, sondern werden intern im Pi-Hole korrekt beantwortet.

 

System aktuell halten

Nicht nur das Pi-Hole, sondern auch das darunterliegende Raspbian bzw. Raspberry Pi OS und die darin installierten Pakete sollte regelmäßig aktualisiert werden.

Raspbian aktualisiert man mit:

  • sudo apt update
  • sudo apt upgrade

Pi-Hole aktualisiert man einfach mit pihole -up.

Unbound muss man manuell aktualisieren, wenn man es auch manuell installiert (kompiliert etc.) hat (siehe oben: der schwierige Weg...). Dazu wiederholt man die wesentlichen Schritte oben. Beispielsweise wurde Anfang März 2019 die Version 1.9.1 bereitgestellt. Außerdem gibt es auch ein neues Bootscript. Man führt durch:

  • Download der Quellen, Entpacken mit:
    sudo wget https://nlnetlabs.nl/downloads/unbound/unbound-1.9.1.tar.gz
    sudo tar xvfz unbound-1.9.1.tar.gz
    cd unbound-1.9.1
  • Compilierung und Installation mit:
    sudo ./configure --prefix=/usr --sysconfdir=/etc --disable-static --with-pidfile=/run/unbound.pid --with-conf-file=/etc/unbound/unbound.conf --with-libevent
    sudo make
    sudo make install
    sudo mv -v /usr/sbin/unbound-host /usr/bin/
  • Bootscript downloaden, compilieren und installieren, damit Unbound auch nach einem Neustart automatisch startet, mit:
    sudo wget http://anduin.linuxfromscratch.org/BLFS/blfs-bootscripts/blfs-bootscripts-20190313.tar.xz
    sudo tar xf blfs-bootscripts-20190313.tar.xz
    cd blfs-bootscripts-20190313
    sudo make install-unbound
  • Aktuelle Datei "root.hints" (Liste der DNS Root Server, die die Domain "." bereitstellen. Die Liste wird ca. alle 6 Monate aktualisiert und die Datei ändert sich dabei in unregelmäßigen Abständen.) downloaden und installieren mit:
    • sudo wget -O /etc/unbound/root.hints https://www.internic.net/domain/named.root
    • sudo wget -O /var/lib/unbound/root.hints https://www.internic.net/domain/named.root
  • Aktuelle Datei "/etc/ssl/certs/ca-certificates.crt" (Sammlung aller benötigten Zertifikate in einer Datei) updaten mit:
    • sudo update-ca-certificates
  • Nun Unbound neu starten mit sudo systemctl restart unbound.service
  • Nun Unbound einmal testen mit z.B. dig pi-hole.net @127.0.0.1 -p 5335
  • Unbound-Status abfragen mit sudo systemctl status unbound.service

 

System optimieren

Es gibt ein paar Punkte, die man noch nachträglich optimieren kann, damit das System etwas besser läuft - oder man zumindest das Gefühl hat, dass es gut läuft.

Firmware-Release ändern auf "latest"

Die Firmware des Raspberry Pi heißt "rpi-eeprom" (Release notes auf Github) und wird mit entsprechenden Werkzeugen verwaltet und aktuell gehalten. Standardmäßig ist die Aktualisierungsroutine sehr konservativ ausgelegt und aktualisiert die Firmware nur in längeren Zeitabständen. Die sogenannte "Release" ist auf "default" (früher "critical") voreingestellt, was so viel heißt wie stabil laufend, ohne großes Risiko, dass Fehler enthalten sind. Ein weiteres "Releases" ist "latest" (früher "stable"), was so viel heißt wie stabil laufend, aber nicht so umfangreich getestet wie "default", aber ausreichend gut. Dann gibt es noch "beta" mit den neuesten und am wenigsten getesteten Funktionen.

Um zumindest etwas früher in den Genuss neuer Funktionen oder auch von (unkritischen) Fehlerbehebungen zu kommen, kann man die "Release" von "default" auf "stable" ändern und dann ein Update versuchen:

  • mit sudo nano /etc/default/rpi-eeprom-update in dieser Datei den Release auf "latest" ändern, sodass dann in der betreffenden Zeile steht
    FIRMWARE_RELEASE_STATUS="latest"
  • danach schauen, ob es ein Update gibt mit sudo rpi-eeprom-update
  • falls ja, updaten mit sudo rpi-eeprom-update -a
  • danach neu starten mit sudo shutdown -r now

Weitere Informationen liefert die offizielle Dokumentation.

 

CPU Governor ändern auf "schedutil"

Der sogenannte CPU Governor kümmert sich darum, mit welcher Geschwindigkeit die einzelnen Kerne der CPU laufen und damit wird natürlich auch beeinflusst, wieviel Wärme entsteht und wieviel Strom verbraucht wird. Stellt man den CPU Governor nun optimal ein, läuft das System schnell und verbraucht trotzdem wenig Strom und bleibt kühl. Dafür wird dann je nach Bedarf des Systems der Takt der CPU vom Governor geändert. Standardmäßig läuft Raspberry Pi OS mit der Einstellung "ondemand", womit bereits eine sehr gute Vorgehensweise existiert. Je nach Bedarf wird der Takt der CPU "nachgeregelt". Diese Einstellung ist aber schon etwas älter und für neuere Kernel-Versionen bietet sich die modernere Einstellung "schedutil" an. Hier richtet sich der Governor nun nach dem Bedarf des Schedulers des Kernel, d.h. direkt nach dem zentralen Mechanismus, der sämtliche Prozesse verwaltet. Weil dieser Scheduler in den letzten Jahren stark modernisiert wurde, ist er nun auch sehr gut als Richtlinie für den CPU Governor geeignet. Um die Einstellung zu ändern, geht man wie folgt vor:

  • Software cpufrequtil installieren mit sudo apt install cpufrequtils
  • Prüfen, welche Einstellungen denn überhaupt zur Verfügung stehen mit cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
  • Falls "schedutil" zur Verfügung steht, dies für das laufende System aktivieren mit sudo sh -c "echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"
  • Damit die Einstellung auch beim nächsten Systemstart erhalten bleibt, eine Datei mit folgendem Inhalt erzeugen: sudo nano /etc/default/cpufrequtils
    GOVERNOR="schedutil"
  • Prüfen (vor und auch nach dem Systemstart) mit: cpufreq-info

 

NAS-Funktion mit Samba auf dem Raspberry Pi

Mit dem DNS-Server haben wir einen Server im Netzwerk, der zwangsläufig stets laufen muss, damit eine DNS-Funktionalität gegeben ist. Damit ist dieser Server auch prädestiniert, um weitere Dienste anzubieten, die auch stets verfügbar sein sollten, aber nicht zu viele Resourcen benötigen. Da der Raspberry Pi 4B auch zwei USB 3-Schnittstellen aufweist, kann man dort auch externe USB-Festplatten mit ausreichend hoher Geschwindigkeit anschließen. Die Daten auf den Festplatten kann man dann im Netzwerk verfügbar machen. Der DNS-Server wird also auch zum NAS-Server. NAS steht für Network Attache Storage.

Ich habe längere Zeit für diese Funktion die sehr mächtige, aber auch komplizierte Software OpenMediaVault (OMV) in Version 5 und später 6 verwendet, diese aber doch als zu umfangreich für meine geringen Bedürfnisse empfunden. Daher habe ich die für mich nötigen Grundfunktionen mit der Software Samba (hier verwendet: Samba 4.13 oder höher) zur Verfügung gestellt. Samba ist viel schneller und einfacher eingerichtet und auch gepflegt als OMV, trotz fehlender GUI.

Dabei geht man wie folgt vor:

  • System aktualisieren und Samba Server (und für Test-Zwecke) den Samba Client (plus weitere evtl. fehlende Pakete, die apt entdeckt) installieren mit
    sudo apt update
    sudo apt install samba samba-common smbclient
  • ursprüngliche Konfigurationsdatei von Samba sichern mit
    sudo mv /etc/samba/smb.conf /etc/samba/smb.conf_orig
  • neue Konfigurationsdatei erstellen mit
    sudo nano /etc/samba/smb.conf
  • In diese Datei kommt folgender Inhalt:
    [global]
    workgroup = WORKGROUP
    security = user
    protocol = SMB3
    interfaces = 127.0.0.0/8 eth0
    bind interfaces only = yes
    unix password sync = yes
    passwd program = /bin/passwd %u

    [freigabe1]
    comment = Freigabe Nr. 1
    path = /media/sda1/freigabe1
    read only = no
    Browseable = yes
    Writeable = yes
    only guest = no
    create mask = 0777
    directory mask = 0777
    Public = no
    Guest ok = no

    [freigabe2]
    comment = Freigabe Nr. 2
    path = /media/sdb1/freigabe2
    read only = no
    Browseable = yes
    Writeable = yes
    only guest = no
    create mask = 0777
    directory mask = 0777
    Public = no
    Guest ok = no

  • Im Bereich [global] werden grundsätzliche Dinge definiert. Mein Beispiel sollte für sehr viele Anwendungen, speziell für den Zugriff von Windows-PCs ausreichend sein. Für weitere Informationen verweise ich auf die sehr gute, aber im Detail etwas veraltete Anleitung vom Elektronik-Kompendium.
    Eine etwas aktuellere Anleitung, speziell zum Thema SMB3, NetBIOS, WSDD findet man bei Dr. Mönchmeyer.
    Im Bereich [freigabe1] etc. wird nun jede Freigabe einzeln definiert. Dabei ist der Name in eckigen Klammern der Name der Freigabe, die im Netzwerk zur Verfügung steht, also z.B. \\192.168.178.2\freigabe1. Der Pfad ist natürlich der hinterlegte Pfad.
  • Nach dem Speichern der Datei testen wir zuerst mit:
    testparm
  • Wir müssen nun noch die angeschlossenen Festplatten in die genannten Verzeichnisse "einhängen", d.h. mounten. Dazu verschaffen wir uns zuerst einen Überblick über alle vorhandenen Datenträger mit:
    sudo fdisk -l
  • Bei mir gibt es beispielsweise zwei Festplatten als /dev/sda1 und /dev/sdb1. Diese mounte ich an zwei Verzeichnisse, die ich vorher anlegen muss (Hinweis: Das jeweilige Unterverzeichnis "freigabe1" (also /media/sda1/freigabe1 und entsprechend /media/sdb1/freigabe2) erstellt Samba selbst.):
    sudo mkdir /media/sda1
    sudo mkdir /media/sdb1
    sudo mount /dev/sda1 /media/sda1
    sudo mount /dev/sda1 /media/sdb1
  • Wir müssen nun noch dafür sorgen, dass die Benutzer auf den Clients auf diese Freigaben zugreifen können. In der Praxis hat es sich sehr(!) bewährt, wenn es auf dem Server und auf den Clients gleichlautende Benutzer mit gleichlautenden Passwörtern angelegt sind. Dies vereinfacht Vieles, obwohl es natürlich auch anders geht...
    Hier habe ich diesen Ratschlag aber befolgt und im System entsprechende Nutzer angelegt (mit useradd -g users -m {USERNAME}). Besonderheit bei Samba ist, dass ich diese System-Benutzer noch einmal als Samba-Benutzer "aktivieren" bzw. einrichten muss. Dazu muss ich aber lediglich noch einmal den Benutzernamen und das (vorhandene) Passwort neu angeben. (Die Einstellungen in [global] sorgen dafür, dass nachträgliche Änderungen an den Benutzern im System und in Samba synchron gehalten werden.):
    smbpasswd -a {USERNAME}
  • Danach starten wir Samba neu mit (Hinweis: Der in Anleitungen auch stets mit startende Service nmbd ist nicht mehr nötig aufgrund des nicht mehr unterstützten NetBIOS. Man sollte nmbd auch ganz deaktivieren mit sudo systemctl disable nmbd):
    sudo systemctl restart smbd
  • Nun ist die Einrichtung eigentlich schon fertig und alles sollte funktionieren - bis zum nächsten Systemstart... - denn dann würden alle gemounteten Datenträger wieder "verschwinden". Wir müssen daher dafür sorgen, dass bei jedem Systemstart die Datenträger automatisch wieder gemountet werden. Dafür benötigen wir die Datei /etc/fstab und die UUIDs der entsprechenden Datenträger (Festplatten, siehe oben). Siehe dazu auch ergänzend wieder die Informationen aus dem Elektronik-Kompendium. und die man-Page von des Befehls mount, in dem auch die Optionen der Datei fstab erläutert werden.
    Zur Anzeige der aktuellen Informationen, d.h. welche UUID zu welchem Datenträger gehört, führen wir aus:
    sudo blkid
  • Damit ergänze ich dann in meiner /etc/fstab folgende Zeilen (die vorhandenen Zeilen unbedingt unverändert lassen!) für meine beiden Festplatten, die als Dateisystem ext4 haben:
    UUID={Ihre-UUID-sda1}    /media/sda1    ext4    defaults,nofail    0    2
    UUID={Ihre-UUID-sdb1}    /media/sdb1    ext4    defaults,nofail    0    2
  • Zwischen den Spalten dieser kleinen Tabelle müssen jeweils ein Tabstopp oder aber vier Leerzeichen sein, das ist wichtig!
  • Hinweis: Die Optionen in der Spalte nach dem Dateisystem können teilweise stark die erreichbaren Transferraten der Freigaben im Netzwerk beeinflussen. Ich habe mit "defaults" hier die besten Ergebnisse in beiden Richtungen (schreibend, lesend jeweils ca. 100 MB/s lt. Windows 10) erzielt.
  • Nach einem Neustart des Servers dürfte sich nun an der Funktion der Freigaben nichts geändert haben.

 

Raspbian Stretch (Debian 9.x) auf Raspbian Buster (Debian 10) aktualisieren

Seit Anfang Juli 2019 gibt es die neue Systemversion von Debian, die Raspbian zugrundeliegt. Obwohl es nicht empfohlen wird "in-place" von einer großen Version zur anderen zu wechseln und lieber frisch anzufangen, habe ich es trotzdem probiert und es ist geglückt. Nach dem Systemupdate musste ich noch Unbound neu installieren (siehe oben). Weitere Anpassungen waren nicht nötig.

Ich bin so vorgegangen:

  • sudo sync
  • sudo apt update
  • sudo apt -y upgrade
  • sudo apt -y dist-upgrade
  • grep -rl stretch /etc/apt/ | sudo xargs sed -i 's/stretch/buster/g'
  • sudo apt update
  • sudo apt -y upgrade
  • sudo apt -y dist-upgrade
  • sudo sync
  • sudo apt -y --purge autoremove
  • sudo apt autoclean
  • sudo shutdown -r now

Bei den zwischendrin auftretenden Fragen habe ich SMB aktualisieren lassen, die Gruppe und den Benutzer "unbound" bestehen lassen, die Dienste automatisch starten lassen, lighthttpd in der alten Version belassen und dhcpd aktualisieren lassen.

Danach habe ich Unbound entfernt und neu installiert in Version 1.9.2 (siehe oben die Anleitung für 1.9.1, entsprechend anpassen).

Insgesamt hat die Prozedur etwa 1 Stunde gedauert.

Aktuell kann ich keine negativen Effekte feststellen, aber das System läuft erst seit kurzer Zeit.

Update:

Aus mir unbekannten Gründen hat Unbound (mittlerweile aktualisiert auf Version 1.9.6) unter Debian 10 aufgehört zu funktionieren. Ich habe die Ursache trotz intensiver Suche nicht gefunden.

Aus diesem Grund habe ich Debian 10 ganz neu aufgesetzt, dann Pi-Hole neu installiert und dann Version 1.9.0 über apt, d.h. über den oben beschriebenen "einfachen Weg" installiert. Das System lief auf Anhieb wieder.