Kategorie: Linux

Stromzähler via IR-Lesekopf auslesen und Daten in Home Assistant erfassen

Meinen Stromzähler lese ich schon länger mit Hilfe eines IR-Schreib-Lesekopfs aus. Dieser hing bisher via USB-Interface an einem Raspberry Pi 3B+ mit vzlogger. Die Daten werden dann in Home Assistant erfasst und visualisiert. Grundsätzlich funktionierte die Variante sehr gut. Allerdings habe ich auf dem Raspberry Pi zwischendurch immer wieder andere Dinge getestet und das ein oder andere Mal musste ich ihn daher neu aufsetzen. Darüber hinaus wollte ich schon länger alle Services meines Smart Homes auf mein Intel NUC umziehen. Gesagt, getan. Heute war es soweit.

Home Assistant Energie Dashboard

Für den Umbau muss sich das Intel NUC natürlich in der Nähe des Stromzählers befinden, da sonst der IR-Schreib-Lesekopf nicht via USB verbunden werden kann. In meinem Fall ist die Anschlussleitung ca. 2 Meter lang. Da sich mein Netzwerkschrank mit dem NUC in der Nähe befindet, war das Kabel geradeso ausreichend. Alternativ kann natürlich auch ein längeres Kabel verlötet werden. Mehr als 5 Meter sollten es aber nicht sein. Eine andere Möglichkeit wäre das Gerät, welches das Auslesen übernimmt, näher an den Lesekopf zu platzieren. Beispielsweise mit einem WLAN-fähigen IR-Schreib-Lesekopf, einem ESP32 oder einem Raspberry Pi. Aber genau diese Variante möchte ich in meinem Fall ja ersetzen… ;-)

Umsetzung

Hier eine kleine Übersicht, wie mein aktueller Aufbau aussieht:

EMH Metering eHZ-K Stromzähler –> IR-Schreib-Lesekopfs mit USB-Schnittstelle –> Intel NUC 11 –> Proxmox 7.3 –> Debian-VM (Docker Host) –> vzlogger 0.8.1 Docker-Container –> Home Assistant 2022.12.0

Zunächst habe ich den IR-Schreib-Lesekopf via USB mit meinem Intel NUC 11 verbunden. Über die Proxmox-Shell kann man prüfen, ob der IR-Schreib-Lesekopf erkannt wurde. Dieser Schritt kann in der Regel übersprungen werden, da das Gerät auch automatisch in der GUI verfügbar ist, sofern es keine Probleme beim Verbinden gab.

lsusb
Bus 001 Device 002: ID 10c4:ea60 Silicon Labs CP210x UART Bridge

In der Proxmox-Weboberfläche habe ich nun das USB-Gerät vom Proxmox-Host an meine Docker-VM durchgereicht. Dies funktioniert bei der entsprechenden VM unter “Hardware”  mit Klick auf den Button “Add” und “USB Device”. Anschließend öffnet sich ein Dialog und unter “Use USB Port” sollte das gewünschte Gerät auftauchen. Dieses auswählen und mit “Add” bestätigen.

Die VM muss neugestartet werden, damit die Änderung wirksam und das USB-Gerät durchgeschleift wird.

Jetzt wird vzlogger als Docker-Container installiert.  Zur Erstellung des Containers nutze ich Portainer.

Als Image verwende ich “stefanschoof/vzlogger:latest”. Darüber hinaus musste ich noch ein paar Dinge anpassen bzw. ergänzen.

  • Port-Forwarding für Nutzung der REST-API einrichten, ich  nutze Port 8081
  • /etc des Containers auf den Docker Host mappen, sodass die Konfigurationsdatei einen Neustart des Containers überlebt
  • User von “vz” in “root” ändern, da ansonsten kein Zugriff auf das Logfile “/var/log/vzlogger.log” möglich ist und vzlogger nicht startet
  • IR-Schreib-Lesekopf vom Docker Host an den Container durchreichen

Für letzteres benötigen wir den genauen Pfad des USB-Geräts am Docker Host. Dieser kann folgendermaßen herausgefunden werden:

ls /dev/serial/by-id/
usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01A62BBF-if00-port0

Vom Host mappen wir also “/dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_01A62BBF-if00-port0” in den Container als “/dev/ttyUSB0”.

Als letztes wird noch die “vzlogger.conf” benötigt. Ich konnte meine funktionsfähige Konfiguration direkt vom Raspberry Pi übernehmen und nach “/var/lib/docker/volumes/vzlogger_data/_data” auf dem Docker Host kopieren. Dadurch wird diese wie oben beschrieben im Container auf “/etc” gemappt.

Meine “vzlogger.conf” sieht folgendermaßen aus:

{
  "retry": 0,
  "daemon": true,
  "verbosity": 0,
  "log": "/var/log/vzlogger.log",
  "push": [],
  "local": {
    "enabled": true,
    "port": 8081,
    "index": true,
    "timeout": 0,
    "buffer": 0
  },
  "meters": [
    {
      "enabled": true,
      "allowskip": false,
      "interval": -1,
      "aggtime": -1,
      "aggfixedinterval": true,
      "channels": [
        {
          "uuid": "5078eef0-ea52-22e7-a3bb-8fdc47e03f0e",
          "identifier": "1-0:1.8.0",
          "api": "null",
          "aggmode": "none"
        },
        {
          "uuid": "9b835b00-ea52-22e7-a5c9-df2124ec3246",
          "identifier": "1-0:2.8.0",
          "api": "null",
          "aggmode": "none"
        },
        {
          "uuid": "88888888-2222-1111-aaaa-dd2222cc1111",
          "identifier": "1-0:16.7.0",
          "api": "null",
          "aggmode": "none"
        }

      ],
      "protocol": "sml",
      "device": "/dev/ttyUSB0",
      "baudrate": 9600,
      "parity": "8n1"
    }
  ]
}

Sofern keine fertige “vzlogger.conf” existiert, kann diese mit Hilfe der Dokumentation, Beispiel-Konfigurationen und des Konfigurations-Editors selber erstellt werden.

Jetzt kann der Container gestartet werden. Wenn im Container Log keine Fehler erscheinen, passt alles.

Über das vorher eingerichtete Port-Forwarding kann man nun im Browser bereits die ausgelesenen Daten einsehen. Bei mir über “http://10.10.70.3:8081”.

In Home Assistant lese ich die Daten vom vzlogger via REST-API aus. Folgenden Code nutze ich in der “configuration.yaml”:

  - platform: rest
    name: stromzaehler_gesamtverbrauch_volkszaehler
    device_class: 'energy'
    state_class: 'total_increasing'
    unit_of_measurement: "kWh"
    scan_interval: 10
    resource: http://10.10.70.3:8081
    value_template: > 
      {% for i in value_json.data %}
         {% if i.uuid == "5078eef0-ea52-22e7-a3bb-8fdc47e03f0e" %}
           {{ i.tuples[0][1]|round(0) / 1000 }}
         {% endif %}
      {% endfor %}
    method: GET
  - platform: rest
    name: stromzaehler_aktuellerverbrauch_volkszaehler
    device_class: 'power'
    state_class: 'measurement'
    unit_of_measurement: "W"
    scan_interval: 10
    resource: http://10.10.70.3:8081
    value_template: > 
      {% for i in value_json.data %}
         {% if i.uuid == "88888888-2222-1111-aaaa-dd2222cc1111" %}
           {{ i.tuples[0][1]|round(0) }}
         {% endif %}
      {% endfor %}
    method: GET

Diese Variante habe ich bereits beim Raspberry Pi verwendet, welche bisher ohne Probleme funktioniert hatte. Daher habe ich lediglich die IP-Adressen angepasst und den Code ansonsten unverändert übernommen. In der Zukunft werde ich das Ganze aber ggf. noch gauf MQTT umbauen.

Kategorien: Linux Smart Home Tutorials

Proxmox Host SSD tauschen / clonen und vergrößern

Seit Ende 2021 betreibe ich mein Intel NUC 11 (RNUC11PAHi50000) als Proxmox-Host. Dort laufen einige Container, meine Home Assistant VM, meine Docker-Host VM und einige weitere VMs. Mit zunehmender Anzahl an Containern und VMs wurde mir die bisher verbaute 500-GB-SATA-SSD zu klein. Als Ersatz sollte eine 1-TByte-NVMe-SSD im M.2-Steckplatz zum Einsatz kommen.

Da mein Proxmox-Host super läuft, wollte ich diesen nicht neu installieren. Also suchte ich nach einer einfachen Möglichkeit, die alte auf die neue SSD zu clonen. Dabei habe ich natürlich direkt an Clonezilla gedacht. Also habe ich die ISO heruntergeladen und via Rufus auf einen USB-Stick gepackt. Anschließend dann vom USB-Stick gebootet und einen “device-to-device” Clonvorgang gestartet. Anfangs sah das ganze noch gut aus, allerdings lief Clonezilla bei der letzten Partition (/dev/nvme0n1p3) in einen Loop. Kurz nach der Meldung “successfully cloned” fing die Wiederherstellung der Partition von vorne an.

Nach kurzer Recherche habe ich herausgefunden, dass Clonezilla wohl generell Probleme mit LVM2 Thin Provisioning hat und auch andere Nutzer davon betroffen sind.

Kurzerhand habe ich dann nach der “successfully cloned” Meldung der letzten Partition das Stromkabel vom NUC entfernt. Daraufhin habe ich die SATA-SSD ausgebaut und im UEFI die NVMe-SSD als Bootdrive festgelegt. Das hat soweit geklappt und Proxmox ist erfolgreich gebootet. Das einzige Problem war, dass die LVM2-Partition nicht automatisch vergrößert wurde.

Aber kein Problem, das kann man ohne Probleme von Hand erledigen.

Partition vergrößern

Im ersten Schritt muss die LVM2-Partition vergrößert werden. Das funktioniert mit “fdisk”. Notiert euch dabei die Startposition von Partition 3. Anschließend könnt ihr Partition 3 entfernen und mit der vollen Größe anlegen. Achtet dabei, dass ihr die LVM2_member Signatur nicht löscht und den Partitionstyp auf “30” (Linux LVM) setzt. Zum Schluss können die Änderungen mit “w” geschrieben werden. Nachfolgend alle Infos zu den einzelnen Schritten:

fdisk /dev/nvme0n1

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 924B151C-5B6A-4F47-931E-88D9625AC43B

Device           Start        End   Sectors   Size Type
/dev/nvme0n1p1      34       2047      2014  1007K BIOS boot
/dev/nvme0n1p2    2048    1050623   1048576   512M EFI System
/dev/nvme0n1p3 1050624 1000215182 999164559 476.4G Linux LVM

Command (m for help): d
Partition number (1-3, default 3):

Partition 3 has been deleted.

Command (m for help): n
Partition number (3-128, default 3):
First sector (1050624-2000409230, default 1050624):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (1050624-2000409230, default 2000409230):

Created a new partition 3 of type 'Linux filesystem' and of size 953.4 GiB.
Partition #3 contains a LVM2_member signature.

Do you want to remove the signature? [Y]es/[N]o: n

Command (m for help): t
Partition number (1-3, default 3):
Partition type or alias (type L to list all): 30

Changed type of partition 'Linux filesystem' to 'Linux LVM'.

Command (m for help): w
The partition table has been altered.
Syncing disks.

Gegebenenfalls kann es notwendig sein, dass ihr noch die Partitionstabelle neu ladet, damit das Betriebssystem die Änderungen mitbekommt. Das kann mit “partx” oder “partprobe” erledigt werden. Alternativ funktioniert auch ein Neustart.

partx -u /dev/nvme0n1p3
partprobe /dev/nvme0n1p3

Physical Volume vergrößern

Nachdem die Partition vergrößert wurde, ist als nächstes das Physical Volume (PV) an der Reihe. Das ist ganz einfach und funktioniert mit diesem Befehl:

pvresize /dev/nvme0n1p3

Logical Volume vergrößern

Im letzten Schritt muss das Logical Volume (LV) vergrößert werden. Dies kann wahlweise auf die maximal verfügbare Größe erfolgen oder ihr könnt auch nur um eine fest definierte Größe erweitern.

lvresize -L +100%FREE pve/data

lvextend -L+10G pve/data
Size of logical volume pve/data_tdata changed from 142.00 GiB (36352 extents) to 154.00 GiB (39424 extents).
Logical volume pve/data_tdata successfully resized.

Wem das Ganze zu viel Arbeit ist, der kann natürlich Proxmox auch neu aufsetzen und die VM- und Container-Backups neu einspielen :-)

Quellen

https://help.univention.com/t/how-to-extend-disk-space/10647

Sie sehen gerade einen Platzhalterinhalt von Standard. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen

Kategorien: Linux Tutorials

Festplatte und Partition einer Linux-VM ohne Neustart vergrößern

Bei der Installation von Linux-VMs wird in vielen Fällen auf LVM verzichtet und das Standard-Paritionslayout verwendet. Dieses besteht üblicherweise aus einer großen Hauptpartition und einer erweiterten Partition mit einem Swap-Volume darauf.

Wenn nachträglich die Festplatte vergrößert werden soll, ist dies nicht ohne weiteres möglich, da das Swap-Volume am Ende der Festplatte eine Vergrößerung der Root-Partition verhindert. Ich bin die letzten Tage auf dieses Problem bei meiner Docker-VM mit Debian 11 gestoßen. Da ich weder die VM neu aufsetzen oder neustarten wollte, war eine einfache Vergrößerung via GParted nicht möglich. Stattdessen habe ich auf die Bordmittel und etwas Handarbeit zurückgegriffen.

Die Ausgangslage sah so aus:

fdisk -l
Disk /dev/sda: 20 GiB, 10737418240 bytes, 20971520 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x55ab4db2

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048 18970623 18968576    9G 83 Linux
/dev/sda2       18972670 20969471  1996802  975M  5 Extended
/dev/sda5       18972672 20969471  1996800  975M 82 Linux swap / Solaris

Die Festplatte im Hypervisor kann direkt vergrößert werden. In meinem Beispiel habe ich diese in Proxmox VE von 10 auf 20 GByte vergrößert.

Der Linux Kernel bekommt von der Vergrößerung allerdings nichts mit. Folgender Befehl löst einen Rescan von sda aus:

echo 1 > /sys/class/block/sda/device/rescan

Über die Kernel-Logs kann geprüft werden, ob der Kernel die größere Festplatte erkannt hat:

dmesg | tail -n 10
[54513.146032] sd 2:0:0:0: Capacity data has changed
[54513.146199] sd 2:0:0:0: [sda] 41943040 512-byte logical blocks: (21.5 GB/20.0 GiB)
[54513.146296] sda: detected capacity change from 10737418240 to 21474836480

Die neue Festplattengröße von 20 GByte wurde erfolgreich erkannt. Im nächsten Schritt muss jetzt die Partition vergrößert werden, da diese nach wie vor unverändert ist.

Ohne nachgelagerte Swap-Partition wäre das mit growpart schnell erledigt und wir könnten sda1 auf die maximal mögliche Größe expandieren:

growpart /dev/sda 1

In unserem Fall funktioniert das leider nicht, da ja noch das Swap-Volume existiert.

Zunächst muss also das Swap-Volume temporär deaktiviert werden.

swapoff /dev/sda5

Jetzt können sowohl Swap (sda5) als auch die Extended-Partition (sda2) gelöscht werden.

fdisk /dev/sda

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): d
Partition number (1,2,5, default 5): 5

Partition 5 has been deleted.

Command (m for help): d 2
Partition number (1,2, default 2): 2

Partition 2 has been deleted.

Command (m for help): w
The partition table has been altered.
Syncing disks.

Anschließend muss die Root-Partition sda1 vergrößert werden. Mit fdisk können Partitionen leider nicht direkt vergrößert werden. Aus diesem Grund muss sda1 gelöscht und mit der richtigen Größe neu erstellt werden. Die Daten bleiben dabei erhalten! Allerdings müsst ihr gut aufpassen, dass ihr den identischen Block als Startposition (wie bei der bisherigen Partition) verwendet. Ebenso müsst ihr noch genügend Platz für das Swap-Volume übrig lassen.

fdisk /dev/sda

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): d
Selected partition 1
Partition 1 has been deleted.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-41943039, default 2048): 2048
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-41943039, default 41943039): 40000000

Created a new partition 1 of type 'Linux' and of size 19.1 GiB.
Partition #1 contains a ext4 signature.

Do you want to remove the signature? [Y]es/[N]o: N

Command (m for help): w
The partition table has been altered.
Syncing disks.

Danach kännen die Extended-Partition sda2 und die logische Swap-Partition sda5 wieder angelegt werden. Zum Schluss bekommt sda5 den Typ 82, welcher “Linux swap” entspricht.

fdisk /dev/sda

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): e
Partition number (2-4, default 2):
First sector (40000001-41943039, default 40001536):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (40001536-41943039, default 41943039):

Created a new partition 2 of type 'Extended' and of size 948 MiB.

Command (m for help): n
All space for primary partitions is in use.
Adding logical partition 5
First sector (40003584-41943039, default 40003584):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (40003584-41943039, default 41943039):

Created a new partition 5 of type 'Linux' and of size 947 MiB.

Command (m for help): t
Partition number (1,2,5, default 5):
Hex code or alias (type L to list all): 82

Changed type of partition 'Linux' to 'Linux swap / Solaris'.

Command (m for help): w
The partition table has been altered.
Syncing disks.

An dieser Stelle muss die Partitionstabelle neu geladen werden. fdisk macht dies unter Debian 11 offensichtlich automatisch. Falls nicht könnt ihr dies folgendermaßen von Hand erledigen:

partprobe /dev/sda

Nun können wir endlich das Dateisystem auf die Partitionsgröße vergrößern.

resize2fs -p /dev/sda1
resize2fs 1.46.2 (28-Feb-2021)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 3
The filesystem on /dev/sda1 is now 4999744 (4k) blocks long.

Um die Swap-Partition müssen wir uns natürlich auch noch kümmern.

mkswap /dev/sda5
Setting up swapspace version 1, size = 947 MiB (992997376 bytes)
no label, UUID=05e1dce8-3798-46c7-b161-e28051c91268

Die neue UUID muss in den beiden Dateien “/etc/fstab” und “/etc/initramfs-tools/conf.d/resume” eingetragen werden.

Zum Abschluss kann die Swap-Partition wieder aktiviert werden:

swapon /dev/sda5
update-initramfs -u

Fertig! Wie ihr seht ist es zwar eine Menge Arbeit, aber so könnt ihr die Root-Partition einer Linux-VM ohne Neustart vergrößern.

Zur Vollständigkeit noch der Output von fdisk, nachdem alles erledigt ist:

fdisk -l
Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x55ab4db2

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1           2048 40000000 39997953 19.1G 83 Linux
/dev/sda2       40001536 41943039  1941504  948M  5 Extended
/dev/sda5       40003584 41943039  1939456  947M 82 Linux swap / Solaris

Kategorien: Linux Tutorials

Proxmox Meldung “No valid subscription” entfernen

Zunächst möchte ich darauf hinweisen, dass Proxmox Virtual Environment (Proxmox VE) ohne Subscription bereits den vollen Funktionsumfang besitzt. Mit Subscription erhält man Zugang zum Enterprise Repository, welches stabile Software- und Sicherheitsupdates sowie technischen Support bietet.

Davon abgesehen erhält man nach dem Einloggen im Web UI eine Meldung, die darauf hinweist, dass keine gültige Subscription vorhanden ist. Diese Meldung erscheint bei jedem Login und sieht folgendermaßen aus:

No Valid subscription

You do not have a valid subscription for this server. Please visit www.proxmox.com to get a list of available options.

Proxmox - No valid subscription

Proxmox – No valid subscription

Wer diese Meldung als störend empfindet, kann diese aber relativ einfach entfernen.

Voraussetzung dazu ist der Zugriff auf die Proxmox-Shell. Entweder via SSH oder über Web-UI-Shell. Der Befehl funktioniert ab Proxmox VE 6.0 und höher.

sed -Ezi.backup "s/(function\(orig_cmd\) \{)/\1\n\torig_cmd\(\);\n\treturn;/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service

Anschließend könnt ihr euch ausloggen, den Browser Cache löschen und bei der nächsten Anmeldung ist der Hinweis verschwunden.

Manuelle Variante

Wer etwas mehr Kontrolle über den Prozess haben möchte, kann die einzelnen Schritte auch von Hand erledigen.

Zunächst navigieren wir zum richtigen Pfad und legen eine Sicherheitskopie der originalen “proxmoxlib.js” an.

cd /usr/share/javascript/proxmox-widget-toolkit
cp proxmoxlib.js proxmoxlib.js.backup

Anschließend öffnen wir die Datei “proxmoxlib.js” und suchen die zu ändernde Codezeile.

nano proxmoxlib.js

Ab Proxmox VE 8.0 und höher lautet die Zeile:

checked_command: function(orig_cmd) {

Nach dieser Zeile fügen wir zwei neue Befehle hinzu. Das sieht dann so aus:

checked_command: function(orig_cmd) {
    orig_cmd();
    return;

Jetzt speichern wir die geänderte Datei ab. Zum Schluss wird der Proxmox Service neugestartet.

systemctl restart pveproxy.service

Nach dem Abmelden und Löschen des Browser Caches ist der Hinweis bei der nächsten Anmeldung verschwunden.

Bei einem Update von Proxmox VE (genauer gesagt des Pakets “proxmox-widget-toolkit”) gehen unsere Änderungen verloren und der ursprüngliche Hinweis erscheint wieder. In diesem Fall muss die Bearbeitung wiederholt werden. Alternativ könnt ihr auch ein Skript erstellen, welches dies automatisch erledigt.

Automatisches Skript

Wer die Meldung vollautomatisch nach jedem Update von “proxmox-widget-toolkit” entfernt haben möchte, muss mit einem Skript arbeiten.

Zuerst erstellen wir unter /root ein Skript, welches dann via APT Hook Skript aufgerufen wird.

Auf dem Host angekommen, legen wir in das /root/ Verzeichnis ein kleines Script an. Dieses erstellt ein Backup der “proxmoxlib.js” und führt die notwendigen Änderungen automatisch durch. Dieses Skript wird wiederrum von dem APT Hook Script aufgerufen.

nano /root/no-sub-script.sh

sed -Ezi.backup "s/(function\(orig_cmd\) \{)/\1\n\torig_cmd\(\);\n\treturn;/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service

Nun muss das Skript noch ausführbar gemacht werden.

chmod +x /root/no-sub-script.sh

Jetzt folgt das APT Hook Script, welches das vorher angelegte Script aufruft.

nano /etc/apt/apt.conf.d/99-no-sub-script

DPkg::Post-Invoke {"sh /root/no-sub-script.sh"};

Nach jeder Aktualisierung oder Neuinstallations eines Pakets wird nun automatisch unser Skript ausgeführt, welches die Subscription-Meldung entfernt.

Mit der Neuinstallation von “proxmox-widget-toolkit” können wir dies direkt testen:

apt --reinstall install proxmox-widget-toolkit

Bitte das Löschen des Browser Caches nicht vergessen!

Kategorien: Linux Tutorials

Raspberry Pi – Docker und Portainer installieren

Wer öfter neue Anwendungen für seinen Raspberry Pi installiert und diese schnell und einfach testen und verwenden möchte, landet früher oder später bei der Nutzung von Containern. Container sind standardisierte Einheiten, die alle notwendigen Dateien enthalten, welche zum Ausführen einer Software erforderlich sind. Neben der Anwendung an sich laufen also auch Bibliotheken, Systemwerkzeuge, Code und Laufzeit im Container.

Docker ist eine Software für das Management von Containern. Mit Hilfe von Docker lassen sich Anwendungen in jeder Umgebung schnell und einfach bereitstellen. Eine hervorragende Ergänzung dazu ist Portainer. Kurz gesagt handelt es sich bei Portainer um eine grafische Benutzeroberfläche für Docker. Damit lässt sich die gesamte Docker-Infrastruktur intuitiv verwalten, was vor allem für Einsteiger ein gewaltiger Vorteil ist. Aber auch erfahrene Nutzer wissen das übersichtliche Management zu schätzen.

Das Konstrukt Docker und Portainer ist schnell aufgesetzt und eine wirklich tolle Umgebung, um mit Containern zu arbeiten. Also perfekt für unseren Raspberry Pi!

Raspberry Pi aktuell halten

Zunächst solltet ihr sicherstellen, dass alles auf dem aktuellsten Stand ist. Dazu müsst ihr die Paketquellen aktualisieren und alle installierten Programme updaten. Anschließend noch den Kernel und die Firmware aktualisieren. Zum Schluss den Raspberry Pi unbedingt neustarten.

sudo apt update
sudo apt upgrade
sudo rpi-update
sudo reboot

Docker Installation

Docker Icon

Die Installation von Docker wird über ein Skript durchgeführt. Dieses wird direkt von Docker zur Verfügung gestellt und führt alle Schritte automatisch ohne weitere Eingaben vom Benutzer durch. Nach wenigen Minuten ist Docker betriebsbereit.

curl -sSL https://get.docker.com | sh

Nach der Installation solltet ihr noch euren Benutzer in die Gruppe “docker” mit aufnehmen, damit ihr ohen root-Rechte mit Docker interagieren könnt. Der zweite Befehl stellt sicher, dass die Änderung wirksam wird. Alternativ hilft aus- und wieder einloggen.

sudo usermod -aG docker $USER
newgrp docker

Zur Überprüfung, ob die Installation erfolgreich verlaufen ist und Docker funktioniert, lassen wir uns die installierte Version anzeigen.

docker version

Portainer Installation

Porainer Logo

Portainer ist im offiziellen Docker Hub als Container erhältlich. Der Befehl holt die aktuellste Version des Portainer-Images für ARM-Prozessoren (genau diese benötigen wir für den Rasperry Pi).

sudo docker pull portainer/portainer-ce:linux-arm

Jetzt wird ein neuer Container gestartet, in dem Portainer läuft.

sudo docker run --restart always --name=portainer -d -p 9443:9443 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:linux-arm --http-disabled

Nach kurzer Zeit ist Portainer bereit und ihr könnt das Webinterface über den HTTPS-Port 9443 und die IP des Rasperry Pis erreichen. Zum Beispiel: https://192.168.180.100:9443

Dort müsst ihr zunächst einen User und das dazugehörige Passwort anlegen:

Portainer Setup

Portainer Setup

Im zweiten Schritt wählt ihr “Docker” aus und klickt unten auf den Button “Connect”. Den Hinweis könnt ihr ignorieren, da wir bereits alles richtig gestartet haben.

Portainer Setup

Portainer Setup

Portainer verwenden

Auf der Startseite könnt ihr direkt die wichtigsten Infos einsehen. In meinem Beispiel läuft ein Docker-Container und es liegen keine Probleme vor.

Portainer Home

Fahren wir direkt mit der wohl wichtigsten Seite fort. Unter “Containers” seht ihr eine Liste aller Container.

Bei 1. findet ihr detaillierte Infos zum jeweiligen Container wie zum Beispiel der aktuelle Status, das verwendete Image, wann der Container erstellt wurde, die verwendete interne IP-Adresse und die verwendeten Ports. Sobald ein Container selektiert ist, kann dieser unter anderem gestartet, gestoppt oder gekillt werden (2.). Mit Klick auf den Button “Add container” kann ein neuer Container erstellt werden (3.).

Portainer Container Overview

Zuerst benötigt der neue Container einen Namen. Im Beispiel nenne ich ihn “Adguard”. Im zweiten Schritt muss das gewünschte Image angegeben werden. Die genaue Bezeichnung lässt sich via Docker Hub herausfinden. Unter “Network ports configuration” lassen sich die Ports (Host + Container) definieren. Die Beschreibung bei Docker Hub liefert hier oft nähere Informationen. In vielen Fällen reicht auch das Setzen der Option “Publish all exposed network ports to random host ports”, dann werden alle vom Container benötigten Ports zufällig vergeben. Unter “Access control” kann der Zugriff auf den Container im Portainer Webinterface eingeschränkt werden. Des Weiteren lassen sich ganz unten eine Menge zusätzlicher Einstellungen konfigurieren. Die wohl wichtigste Option ist die “Restart Policy”. Damit legt ihr fest, was mit dem Container passieren soll, wenn euer Raspberry Pi neustartet.

Sobald alle Einstellungen getroffen sind, kann der neue Container mit Klick auf “Deploy the container” erstellt werden.

Portainer create new container

Portainer aktualisieren

Zum Aktualisieren auf eine neue Version müsst ihr Portainer zunächst stoppen und dann entfernen. Keine Angst, eure Daten und die anderen Container werden dadurch nicht beeinflusst.

docker stop portainer
docker rm portainer

Anschließend wird das lokale Portainer-Image aktualisiert und Portainer danach wieder deployed.

sudo docker pull portainer/portainer-ce:linux-arm
sudo docker run --restart always --name=portainer -d -p 9443:9443 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:linux-arm --http-disabled

Danach könnt ihr euch wieder wie gewohnt am Webinterface anmelden.

Raspberry Pi – Installation und Betrieb von WireGuard

WireGuard Logo

Obwohl die Bekanntheit von WireGuard in den letzten Monaten stark zugenommen hat, ist das VPN-Protokoll bzw, die VPN-Software immer noch verhältnismäßig unbekannt. Ich nutze WireGuard seit einigen Monaten und möchte es nicht mehr missen. Vor allem der schnelle Verbindungsaufbau, das exzellente Roaming-Verhalten und die gute Performance haben mich überzeugt.

Was sich genau hinter WireGuard verbirgt und wie die Software arbeitet, habe ich bereits in meinem Artikel “​WireGuard – neues VPN-Protokoll mit großer Zukunft” beschrieben. Jetzt folgt sozusagen der zweite Teil, in dem ich detailliert auf die Einrichtung unter Raspbian Buster und Android eingehe.

WireGuard Installation

Update 13.05.2021: Artikel auf das aktuellste Raspberry Pi OS angepasst. Dieser nutzt den Linux-Kernel 5.10, in welchem das WireGuard Modul enthalten ist.
Die Installationsanleitung funktioniert nicht bei folgenden Raspberry Pi Modellen: 1, 2 (Ausnahme v1.2), Zero & Zero W. Bei diesen Modellen fehlen benötigte CPU-Features und WireGuard muss dort von Hand compiliert werden. Wie das geht habe ich relativ am Ende meines Artikels aufgezeigt. Davon abgesehen macht die Nutzung auf diesen Modellen aber nur eingeschränkt Spaß.

Zunächst bringen wir die Paketquellen und alle Pakete auf den aktuellen Stand.

sudo apt update
sudo apt upgrade

Nachdem dies erledigt ist, widmen wir uns der Installation von WireGuard.

sudo apt install wireguard

Die Installation an sich ist damit erledigt. Allerdings fehlt ab Raspberry Pi OS Bullseye iptables, d.h. dieses müssen wir auch noch installieren:

sudo apt install iptables

Jetzt können wir mit der Konfiguration fortfahren.

Generierung der benötigten Schlüsselpaare

Zum Start benötigen wir jeweils einen privaten und öffentlichen Schlüssel für den Client und den Server.

Die Erstellung der Keys wird im Verzeichnis “/etc/wireguard” durchgeführt. Damit alle Dateien bei der Erstellung direkt restriktive Berechtigungen haben, muss die umask auf 077 gesetzt werden.

sudo su
cd /etc/wireguard
umask 077
wg genkey | tee peer1_private.key | wg pubkey > peer1_public.key
wg genkey | tee server_private.key | wg pubkey > server_public.key

Mittels “ls” prüfen wir, ob alle vier Dateien erstellt wurden:

ls
peer1_private.key  peer1_public.key  server_private.key  server_public.key

Zum Schluss können die Keys mittels “cat” ausgegeben werden, da wir diese später sowieso benötigen.

exit
sudo cat /etc/wireguard/peer1_private.key
sudo cat /etc/wireguard/peer1_public.key
sudo cat /etc/wireguard/server_private.key
sudo cat /etc/wireguard/server_public.key

WireGuard Server Konfiguration erstellen

Im ersten Schritt aktivieren wir das IPv4 Forwarding in der Datei “/etc/sysctl.conf”. Dies kann entweder mit Entfernen der Auskommentierung der Zeile “net.ipv4.ip_forward = 1” oder alternativ mit diesem Befehl erfolgen:

sudo perl -pi -e 's/#{1,}?net.ipv4.ip_forward ?= ?(0|1)/net.ipv4.ip_forward = 1/g' /etc/sysctl.conf

Wer IPv6 nutzt, muss stattdessen entsprechend die Auskommentierung der Zeile “net.ipv6.conf.all.forwarding=1” aufheben.

Anschließend muss der Raspberry Pi neugestartet werden.

sudo reboot

Wir überprüfen den Status mit folgendem Befehl:

sysctl net.ipv4.ip_forward

Wenn das IPv4 Forwarding aktiv ist muss als Ergebnis “net.ipv4.ip_forward = 1” zurückgegeben werden.

Jetzt erstellen wir die WireGuard-Konfiguration “/etc/wireguard/wg0.conf”. Welchen Editor ihr bevorzugt, bleibt natürlich euch überlassen.

sudo vim /etc/wireguard/wg0.conf

Folgendes Template könnt ihr als Ausgangsbasis nutzen.

[Interface]
Address = 100.64.0.1/24
ListenPort = 51820
PrivateKey = <insert server_private.key>

#replace eth0 with the interface open to the internet (e.g might be wlan0)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

#Client1 Smartphone
[Peer]
PublicKey = <insert peer1_public.key>
AllowedIPs = 100.64.0.2/32

Neben den IP-Adressen müsst ihr den privaten Schlüssel vom Server und den öffentlichen Schlüssel vom Client ergänzen. Außerdem müsst ihr bei den iptables-Regeln evtl. die Netzwerkschnittstelle anpassen. Optional könnt ihr zudem einen anderen Port definieren. Wenn alles erledigt ist, solltest ihr die Datei unbedingt speichern.

Die für den Tunnel verwendeten IP-Adressen, dürfen sich mit den lokal verwendeten, privaten IPv4-Blöcken (RFC 1918) nicht überschneiden. Beim Einsatz einer FRITZ!Box als Router wird lokal standardmäßig 192.168.178.0/24 verwendet, d.h. alle anderen Adressbereiche können ohne Probleme genutzt werden.

Eine elegante Alternative ist die Verwendung von IP-Adressen (100.64.0.0/10), die für Carrier-Grade-NAT (RFC 6598) reserviert sind. Damit ist sichergestellt, dass die Tunnel-IPs nie mit den privaten Adressbereichen kollidieren können.

WireGuard Client Konfiguration erstellen

Am besten erstellt ihr für jeden Client eine eigene Konfiguration.

sudo vim /etc/wireguard/peer1.conf

Folgendes Template könnt ihr als Ausgangsbasis nutzen.

[Interface]
Address = 100.64.0.2/32
DNS = 192.168.178.1
PrivateKey = <insert peer1_private.key>

#Server
[Peer]
PublicKey = <insert server_public.key>
Endpoint = t6bibneqwcjxplum.myfritz.net:51820
AllowedIPs = 0.0.0.0/0, ::/0
#PersistentkeepAlive = 25

Hier müsst ihr unter “[Interface]” die IP-Adresse des Clients anpassen und den gewünschten DNS-Server eintragen. In meinem Beispiel verwende ich die private IP der FRITZ!Box. Wer daheim Pi-Hole im Einsatz hat, kann hier die Pi-Hole Adresse eintragen und kommt somit auch von unterwegs in den Genuss der Werbefreiheit.

Außerdem müsst ihr noch den privaten Schlüssel des Clients ergänzen.

Unter “[Peer]” tragt ihr zunächst den öffentlichen Schlüssel des Servers ein.

Anschließend folgt die Internetadresse, unter welcher der WireGuard-Server erreichbar ist. Üblicherweise gibt es hier zwei Dinge zu beachten. Bei eurem Internetanschluss daheim, bekommt ihr mit großer Wahrscheinlichkeit eine dynamische IP-Adresse vom Provider zugewiesen. Der WireGuard-Client müsste die wechselnden IP-Adressen stets kennen, um sich zu verbinden. Als Hilfe kommt hier ein dynamischer DNS-Anbieter ins Spiel, der einen festen Domainnamen bereitstellt und dahinter automatisch die jweils aktuelle IP-Adresse zuweist. Bei Verwendung einer FRITZ!Box könnt ihr beispielsweise den Dienst “MyFRITZ!” nutzen. Eine andere Alternative wäre FreeDNS. Der zweite Punkt ergibt sich, wenn der Raspberry Pi in eurem Heimnetzwerk steht. In diesem Fall müsst ihr an eurem Router ein Port-Forwarding einrichten (UDP 51820), sodass der WireGuard-Traffic des Clients auf den Server weitergeleitet wird.

Unter “AllowedIPs” wird definiert, welche IP-Ranges über das WireGuard-VPN geroutet werden. Mit “0.0.0.0/0, ::/0” wird der komplette IPv4- und IPv6-Traffic geroutet (full tunnel). Mit 192.168.178.0/24 könnt ihr z.B. nur euer Heimnetzwerk routen (split tunnel).

“PersistentKeepalive” ist standardmäßig deaktiviert. Zunächst ein paar Hintergrundinfos um einzuordnen, ob ihr dieses Feature benötigt oder nicht. Normalerweise ist WireGuard nicht sehr gesprächig und sendet nur Daten, wenn etwas zu übertragen ist. Ansonsten verhält sich WireGuard ruhig. Wenn sich der Server hinter einem NAT oder einer Firewall befindet und der Client für eine bestimmte Zeit keine Daten zum Server sendet, entfernt der NAT-Router bzw. die Firewall den Host-Status aus der Verbindungstabelle. Falls jetzt der Server ein Paket zum Client sendet, kommt dieses nicht an, da der NAT-Router bzw. die Firewall nicht weiß, was mit dem Paket zu tun ist. Mit der Option “PersistentKeepalive” sendet der Client alle x Sekunden ein leeres Paket, um die Verbindung aufrechtzuhalten. Ein Wert von 25 Sekunden hat sich in der Praxis bewährt und funktioniert mit einem Großteil von Firewalls und NAT-Routern.

Kurz zusammengefasst benötigt ihr dieses Feature also nur, wenn ihr vom Server euren Client erreichen möchtet, obwohl dieser seit längerer Zeit keine Pakete gesendet hat. Die meisten Benutzer werden dieses Feature nicht benötigen. Falls doch, einfach die Auskommentierung der Zeile rückgängig machen.

WireGuard Server starten

Nun können wir WireGuard auf dem Server starten. Anstatt alle einzelnen Schritte manuell mit dem “wg”-Tool durchzuführen, bedienen wir uns beim Tool “wg-quick”.

sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 100.64.0.1/24 dev wg0
[#] ip link set mtu 1432 up dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Die MTU von 1432 bezieht sich auf PPPoE mit IPv4. Bei IPv6 müsst ihr die MTU auf 1412 setzen. Wenn ihr Kabelinternet habt, dann sind Werte von 1440 bei IPv4 und 1420 bei IPv6 richtig.

Danach prüfen wir den Status der wg0-Schnittstelle.

sudo wg
interface: wg0
  public key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxljP1wpITnI=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtJd9/esWN4=
  allowed ips: 100.64.0.2/32

Der Server läuft und ist für die Verbindung des Clients bereit.

WireGuard beenden funktioniert mit diesem Befehl:

sudo wg-quick down wg0

Wenn WireGuard beim Systemstart automatisch geladen werden soll, kann dies mit folgendem Befehl realisiert werden:

sudo systemctl enable wg-quick@wg0
Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service → /lib/systemd/system/wg-quick@.service.

Der Daemon kann folgendermaßen gesteuert werden. Dabei müsst ihr allerdings darauf achten, dass ihr WireGuard zuerst beendet, sofern ihr es manuell gestartet habt.

sudo systemctl start wg-quick@wg0
sudo systemctl stop wg-quick@wg0
systemctl status wg-quick@wg0

Zum Schluss werden die Berechtigungen von “/etc/wireguard/” und allen Dateien noch einmal korrigiert. Damit wird sichergestellt, dass nur root die entsprechenden Berechtigungen besitzt.

sudo chown -R root:root /etc/wireguard/
sudo chmod -R og-rwx /etc/wireguard/*

WireGuard Client unter Android einrichten

Die Einstellungen in der Android-App können manuell, mittels einer Datei oder mit einem QR-Code erfolgen. Die letzte Variante ist dabei am bequemsten. Hierfür muss auf dem Server der QR-Code erstellt werden.

sudo apt install qrencode

Nach dem Installieren von “qrencode” kann der QR-Code von der Client-Konfiguration erstellt werden:

sudo cat /etc/wireguard/peer1.conf | qrencode -t ansiutf8

Auf dem Android-Gerät muss zunächst die WireGuard App via Google Play installiert werden. Daraufhin kann der erstellte QR-Code mit der App gescannt werden, um die Konfiguration zu importieren. Nachdem ein Name vergeben wurde, kann die Verbindung aktiviert werden.

Mit einem Klick auf den gerade erstellten Tunnel werden einige Infos angezeigt, unter anderem auch eine Trafficstatistik.

Auf dem Server kann ebenfalls der Status ausgegeben werden. Dort werden unter anderem alle verbundenen Clients angezeigt:

sudo wg
interface: wg0
  public key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxljP1wpITnI=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxtJd9/esWN4=
  endpoint: 11.12.13.14:53019
  allowed ips: 100.64.0.2/32
  latest handshake: 56 seconds ago
  transfer: 927.04 KiB received, 64.85 MiB sent

Der Client kann nun auch via Ping erreicht werden:

ping 100.64.0.2
PING 100.64.0.2 (100.64.0.2) 56(84) bytes of data.
64 bytes from 100.64.0.2: icmp_seq=1 ttl=64 time=95.9 ms
64 bytes from 100.64.0.2: icmp_seq=2 ttl=64 time=112.4 ms
64 bytes from 100.64.0.2: icmp_seq=3 ttl=64 time=71.7 ms

Noch zwei kleine Tipps für die Android-App. Ich importieren die Konfig vom Server immer zweimal. Einmal als “full tunnel” mit “0.0.0.0/0, ::/0” und einmal als “split tunnel”, lediglich mit dem Heimnetzwerk eingetragen, z.B. 192.168.178.0/24. So habt ihr volle Kontrolle und könnt je nach Situation den richtigen Tunnel nutzen.

Beim Bearbeiten eines Tunnels (Tunnel Infos anzeigen und dann rechts oben auf das Stift-Icon) könnt ihr außerdem festlegen, welche Apps keinen Traffic über den Tunnel schicken dürfen.

Troubleshooting

WireGuard ist ein Kernel-Modul, das via DKMS automatisch installiert wird, sobald das System einen neuen Kernel benutzt. In seltenen Fällen kann es jedoch passieren, dass WireGuard nicht automatisch eingebunden wird und mit dem neuen Kernel nicht mehr funktioniert.

In diesem Fall sollte zunächst geprüft werden, ob das WireGuard Modul geladen wurde:

lsmod | grep wireguard

Falls nicht kann es hilfreich sein, das Kernel-Modul neu zu konfigurieren:

sudo dpkg-reconfigure wireguard-dkms
sudo modprobe wireguard

Wenn dies keine Abhilfe schafft, könnt ihr noch folgendes ausprobieren:

sudo apt remove wireguard
sudo apt install bc libncurses5-dev
sudo apt install wireguard

Sollte dies auch keine Besserung bringen, könnt ihr alternativ das WireGuard Kernel Module und das wg Tool selber kompilieren. Davor muss aber sichergestellt sein, dass alle installierten WireGuard-Pakete deinstalliert sind!

sudo apt remove wireguard
# Toolchain installieren
sudo apt install libmnl-dev raspberrypi-kernel-headers build-essential git pkg-config
#Code laden
git clone https://git.zx2c4.com/wireguard-linux-compat
git clone https://git.zx2c4.com/wireguard-tools
# Kernel Module und das wg Tool kompilieren und installieren
make -C wireguard-linux-compat/src -j$(nproc)
sudo make -C wireguard-linux-compat/src install
make -C wireguard-tools/src -j$(nproc)
sudo make -C wireguard-tools/src install
# Neustarten und fertig
sudo reboot

Die aktuell installierte Version könnt ihr am besten via “dmesg” herausfinden:

dmesg | grep wireguard
[  466.479104] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[  466.479115] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.

Quellen

  • https://www.wireguard.com/install/
  • https://github.com/adrianmihalko/raspberrypiwireguard
  • https://www.reddit.com/r/pihole/comments/bnihyz/guide_how_to_install_wireguard_on_a_raspberry_pi/
  • https://emanuelduss.ch/2018/09/wireguard-vpn-road-warrior-setup/
  • https://www.bachmann-lan.de/raspberry-pi-mit-wireguard-als-vpn-server-mit-wireguard/

WireGuard – neues VPN-Protokoll mit großer Zukunft

WireGuard Logo

WireGuard erfreut sich seit geraumer Zeit wachsender Beliebtheit. Hinter WireGuard verbirgt sich sowohl ein VPN-Protokoll, als auch eine VPN-Software. Während es vor zwei Jahren quasi unbekannt war, hat die Bekanntheit in den letzten Monaten stark zugenommen. Grund dafür ist neben der guten Performance und dem schnellen Verbindungsaufbau sicherlich auch die Aufnahme in den stabilen Linux Kernel 5.6, welcher Anfang April 2020 erscheinen dürfte.

Ich selbst bin im Herbst 2019 auf WireGuard gestoßen, als jemand in einem Forum WireGuard vorstellte und als “heißen Scheiß” bezeichnet hatte. Mittlerweile nutze ich WireGuard seit mehreren Monaten und kann dieser Aussage nur zustimmen :-)

Einleitung

Das VPN-Protokoll WireGuard und die gleichnamige Open Source Software wurden von Jason A. Donenfeld ins Leben gerufen. WireGuard sieht sich selber als extrem einfache, aber dennoch schnelle und moderne VPN-Lösung. Gleichzeitig soll es durch die Nutzung der neuesten Kryptographie-Techniken extrem sicher sein. Im direkten Vergleich mit IPsec und OpenVPN soll es leistungsfähiger, einfacher, schlanker und schneller sein.

Ursprünglich wurde WireGuard nur für den Linux-Kernel entwickelt, ist mittlerweile aber zudem für Windows, macOS, BSD, iOS und Android verfügbar.

Die ersten Snapshots wurden im Juni 2016 veröffentlich. Zwei Jahre später im Juni 2018 wurde der Code und das Protokoll als experimentell bezeichnet und darauf hingewiesen, dass noch kein stabiles Release existiert. Dies trifft bis zum heutigen Tag zu, könnte sich aber bald ändern.

Rund eineinhalb Jahre nach dem Vorschlag von Donenfeld zur Aufnahme in den Hauptzweig ist es nun soweit. Linus Torvalds hat vor wenigen Tagen den Entwicklungszweig Net-Next in den Hauptzweig der Kernel-Entwicklung integriert. Damit wird WireGuard erstmals Teil eines stabilen Linux-Kernels. Der Kernel 5.6 wird für Anfang April erwartet. Grund der langen Verzögerung war der Crypto-Unterbau von WireGuard, welcher einen anderen Ansatz als die Crypto-API des Linux-Kernels verfolgt und deshalb für Unstimmigkeiten gesorgt hatte. Letztlich wurden die neuen Crypto-Funktionen aber im kürzlich veröffentlichten Kernel 5.5 umgesetzt.

Technik

Der Grundgedanke hinter WireGuard ist erfrischend neu und simpel. WireGuard arbeitet ausschließlich auf Schicht 3 des OSI-Modells und ermöglicht die Netzwerkkopplung auf Peer-to-Peer-Basis. Softwareseitig gibt es keine Unterschiede zwischen den Teilnehmern. Alleine die Konfiguration entscheidet, ob ein Peer als Client oder Server arbeitet. Aus diesem Grund sind sogenannte Road-Warrior-Szenarien mit einem zentralen Server und mehreren Clients kein Problem.

Unterstützt wird neben IPv4 auch IPv6. Des Weiteren kann IPv4 in IPv6 getunnelt werden und umgekehrt. Die Verbindung zwischen zwei Peers wird über einen einzelnen, frei wählbaren UDP-Port geregelt. Standardmäßig ist dies UDP-Port 51820.

Zum Verbindungsaufbau wird auf beiden Seiten der VPN-Verbindung lediglich ein Schlüsselpaar benötigt. Der private Schlüssel bleibt dabei lokal, der öffentliche Schlüssel wird der Gegenstelle bekannt gemacht. Auf eine Zertifikat-Infrastruktur kann getrost verzichtet werden. Außerdem kann optional ein symmetrischer Schlüssel (PSK) verwendet werden, der die Verbindung zusätzlich sichert.

Andere VPN-Protokolle unterstützen eine Vielzahl von Algorithmen zum Schlüsselaustausch, zum Chiffrieren und zur Hash-Berechnung. WireGuard geht einen anderen Weg und kennt für jede Aufgabe nur einen fest codierten Algorithmus. Curve25519 für den Schlüsselaustausch, ChaCha20 für die Verschlüsselung, Poly1305 für die Authentifizierung, BLAKE2 für das Hashing und SipHash24 für die Hashtable.

Durch die vollständige Neuentwicklung und den Fokus auf Grundfunktionen kann komplett auf Altlasten verzichtet werden, was sich auch im Quelltext zeigt. Während OpenVPN und IPSec auf mehrere Hunderttausend Zeilen Code kommen, begnügt sich WireGuard mit ca. 7.000 Zeilen.

Ein weiteres Merkmal ist das eingebaute “Roaming”. Wechselt ein Peer (Client), also z.B. ein Smartphone, zwischen WLAN und Mobilfunknetz, bleibt die WireGuard-Verbindung bestehen und der Anwender bekommt davon nichts mit. Selbst wenn es in seltenen Fällen zu einem Verbindungsabbruch führt, ist die Verbindung fast unmittelbar wiederhergestellt. Andere VPN-Protokolle wie IPSec oder OpenVPN sind im direkten Vergleich quälend langsam.

Die gute Performance ist unter anderem darin begründet, dass WireGuard unter Linux direkt im Kernel arbeitet. Somit entfallen häufige Kontextwechsel zwischen Userland und Kernel und die Datenpakete können deutlich schneller abgearbeitet werden. Zudem besitzt WireGuard spezielle Optimierungen für die MIPS-Prozessor-Architektur, sodass es auch für leistungsschwache Geräte interessant ist.

Fazit

Ich habe WireGuard vor ca. fünf Monaten auf meinem Raspberry Pi und meinem Smartphone installiert. Seitdem ist mein Smartphone zu 100% über den WireGuard-VPN-Tunnel online. Weder daheim noch unterwegs musste ich bisher irgendwelche Probleme feststellen. Die Performance ist super und das Roaming-Verhalten spitze. Wie vom Entwickler versprochen gibt es hier keine Abbrüche oder Verzögerungen. Einziger Negativpunkt ist das spärliche Logging auf beiden Seiten.

In einem weiteren Artikel werde ich detailliert auf die Einrichtung unter Raspbian Buster und Android eingehen. Stay tuned!

Raspberry Pi – SSH Hardening

Raspberry Pi Logo

Die wohl am häufigsten genutzte Methode zur Administration eines Raspberry Pis ist Secure Shell (SSH). In den aktuellen Raspbian Versionen ist SSH bereits integriert und muss lediglich aktiviert werden.

Im aktuellen Raspbian Buster (basiert auf Debian 10 Stable) kommt OpenSSH in Version 7.9p1 zum Einsatz. Die Standard-Konfiguration ist in puncto Sicherheit zwar in Ordnung, aber mit einigen Handgriffen lässt sich die Administrationsschnittstelle deutlich besser absichern. Damit steigt die Hürde für potenzielle Angreifer deutlich. Dies ist vor allem wichtig, wenn euer Pi aus dem Internet erreichbar ist.

Mein Artikel bezieht sich auf Raspbian Buster mit OpenSSH 7.9, ist aber größtenteils auch für andere Distributionen und OpenSSH-Versionen anwendbar.

Grundlagen und hilfreiche Befehle

OpenSSH besteht aus zwei Teilen: Dem Server Daemon (sshd) und dem Client (ssh). In diesem Tutorial widme ich mich ausschließlich sshd. Die Konfigurationsdatei des Servers befindet sich hier:

/etc/ssh/sshd_config

Der Status des sshd-Daemons kann mit folgendem Befehl abgefragt werden:

systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-11-02 08:44:33 GMT; 2 weeks 3 days ago

Damit könnt ihr sicherstellen, dass sshd automatisch startet (enabled) und gerade läuft (active (running)). Des Weiteren seht ihr auch die 10 letzten Logeinträge.

Mit folgendem Befehl könnt ihr die aktiven SSH-Sessions einsehen:

ss -n -o state established '( dport = :22 or sport = :22 )'

Bei Änderungen an der Server-Konfiguration empfehle ich diese vor dem Neustart des Dienstes zu prüfen. Damit könnt ihr Syntaxfehler und Probleme mit ungültigen Einstellungen in “/etc/ssh/sshd_config” verhindern:

sudo sshd -t

Zum Anwenden der Änderungen empfehle ich sshd folgendermaßen neuzustarten. Mit dieser Variante besteht die größte Chance, dass offene Remote-Sessions nicht geschlossen werden.

sudo systemctl reload ssh.service

SSH-Server: Einstellungen

Wie oben bereits erwähnt lassen sich die Einstellungen in der Datei “/etc/ssh/sshd_config” anpassen und sind nach einem Neustart von sshd aktiv. Einige Einstellungen sind bereits standardmäßig deaktiviert. Diese sind in der Config-Datei auskommentiert. Es schadet jedoch nicht diese noch einmal zu überprüfen.
Über die Protokoll-Version müssen wir uns keine Sorgen machen, da ab OpenSSH 7.0 SSH Version  1 bereits beim Kompilieren deaktiviert wird.
Standardmäßig hört der Server auf Port 22. Dieser kann geändert werden, um beispielsweise die Anzahl der Angriffe zu verringern. Einen Sicherheitsgewinn gibt es meiner Meinung nach nicht.
Wenn der Server mehrere IP-Adressen besitzt, kann über “ListenAdress” eingeschränkt werden, auf welcher IP eine Verbindung akzeptiert werden soll.

Port22
ListenAddress 192.168.10.10
#ListenAddress ::

Da wir auf unserem Raspberry keine grafische Benutzeroberfläche haben, können wir das X11-Protokoll getrost deaktivieren. Davon abgesehen wird vom Server ein Rückkanal zum Client geöffnet, was sicherheitstechnisch nicht ganz unbedenklich ist.

X11Forwarding no

Mittels .rhosts-Datei kann der Zugriff von fremden Systemen lediglich anhand der IP-Adresse erlaubt werden. Dieser Zugriff ist heutzutage nicht mehr üblich und daher standardmäßig deaktiviert.

IgnoreRhosts yes

Useraccounts ohne Passwort dürfen sich nicht via SSH anmelden. Auch diese Option ist per Default deaktiviert.

PermitEmptyPasswords no

Eine direkte Anmeldung mit dem Account “root” sollte in der Regel nicht erlaubt werden (PermitRootLogin no). Falls dies aus bestimmten Gründen dennoch notwendig sein sollte, ist die Option “prohibit-password” in Ordnung. Diese ist standardmäßig gesetzt und erlaubt nur eine Public-Key-Authentifizierung mit dem root Account.

PermitRootLogin prohibit-password

Die maximale Zahl der Anmeldeversuche pro User sind standardmäßig auf 6 gesetzt. Ich würde empfehlen den Wert weiter zu verringern, beispielsweise auf 3.

MaxAuthTries 3

Inaktive Sessions können nach einer bestimmten Zeit automatisch beendet werden. Mit “ClientAliveInterval” wird festgelegt, nach wie vielen Sekunden Inaktivität der Server eine Nachricht an den Client sendet. “ClientAliveCountMax” ist die Anzahl, wie oft dies der Server wiederholt, bis der Client getrennt wird. In meinem Beispiel oben wird der Client nach 15 Minuten getrennt.

ClientAliveInterval 300
ClientAliveCountMax 3

Normalerweise erfolgt die Anmeldung am Server mit Username und Passwort. Eine bessere Alternative ist die Public-Key-Authentifizierung. Diese ist bereits standardmäßig erlaubt.

PubkeyAuthentication yes

Zur Einrichtung muss auf dem Client zunächst ein neues Schlüsselpaar generiert werden. Wählt hier “Ed25519”, sofern nichts gravierendes dagegenspricht. Unter Windows könnt ihr dies prima mit PuTTYGen erledigen. Ab Windows 10 1809 kann dies auch direkt via PowerShell oder der Eingabeaufforderung erledigt werden. Unter Linux nutzt ihr ssh-keygen. Der Einsatz einer Passphrase ist zwar optional, aber ich empfehle ein starkes Passwort zu verwenden, um den Key vor Missbrauch zu schützen.

ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519

Im nächsten Schritt muss der Public Key auf dem Server eingetragen werden. PuTTYGen stellt euch den String bereit, den ihr in die “authorized_keys” kopieren müsst.

ssh pi@192.168.10.10
mkdir ~/.ssh
chmod 700 ~/.ssh
vi ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Unter Linux geht dies mit “ssh-copy-id” etwas einfacher.

ssh-copy-id -i ~/.ssh/id_ed25519.pub pi@192.168.10.10

Abschließend solltet ihr prüfen, ob die Anmeldung via Public-Key-Authentifizierung funktioniert. Falls ja, könnt ihr nun die Passwort-Anmeldung an eurem SSH-Server deaktivieren.

PasswordAuthentication no
ChallengeResponseAuthentication no

SSH-Server: Cipher-Suites und Verschlüsselungsalgorithmen

Zur Prüfung, welche Cipher-Suites und Verschlüsselungsalgorithmen euer OpenSSH-Server anbietet, eignet sich das Python-Script “ssh-audit”:

cd ~
wget https://github.com/jtesta/ssh-audit/releases/download/v2.4.0/ssh-audit-2.4.0.tar.gz
tar -xvzf ssh-audit-2.4.0.tar.gz
~/ssh-audit-2.4.0/ssh-audit.py 192.168.10.10

Alternativ könnt ihr auch Nmap dazu verwenden:

nmap -p22 -n -sV --script ssh2-enum-algos 192.168.10.10

Schauen wir uns zunächst die Algorithmen für den Schlüsseltausch an. Falls Curve25519 nicht ausreichend ist, könnt ihr noch “diffie-hellman-group-exchange-sha256” hinzufügen.

# Allow only secure key exchange algorithms
KexAlgorithms curve25519-sha256@libssh.org

Danach folgen die Schlüssel bzw. Algorithmen für die Authentifizierung. Hier solltet ihr alle vorhandenen Host-Schlüssel löschen und neu generieren.

cd /etc/ssh
sudo rm ssh_host_*key*
sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
sudo ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

Anschließend könnt ihr in eure “sshd_config” folgendes eintragen:

# Allow only secure server authentication algorithms
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKeyAlgorithms ssh-ed25519,ssh-rsa

Als nächstes nehmen wir uns den symmetrischen kryptographischen (Ciphers) sowie MAC (Message Authentication Code) Algorithmen an. Folgendes gilt aktuell als sicher:

# Allow only secure symmetric ciphers
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

# Allow only secure message authentication codes
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Prüft zur Sicherheit, dass ihr vor dem Neustart von sshd eine Verbindung habt, damit ihr euch im Notfall nicht den Zugang zu eurem Raspberry absägt.

Einen guten Artikel mit weiteren Details über die einzelnen Cipher-Suites und Verschlüsselungsalgorithmen findet ihr hier: https://stribika.github.io/2015/01/04/secure-secure-shell.html

Veeam Backup & Replication 9.5 Community Edition – kostenlose Version mit mehr Möglichkeiten

Veeam Backup & Replication 9.5 Update 4

Das vor einigen Tagen veröffentlichte Veeam Backup & Replication 9.5 Update 4 bringt trotz des kleinen Versionssprungs einige Neuerungen mit sich. Neben zahlreichen neuen Features gibt es auch eine Änderung bei der Lizenzierung, die vor allem Privatleute und kleine Firmen erfreuen dürfte.

Das Update 4 von Backup & Replication 9.5 ersetzt die bisherige Free Edition durch die Community Edition. Dabei können alle Features der Standard Version benutzt werden, es existiert lediglich eine Beschränkung auf 10 Instanzen. Die 10 Instanzen können beliebig kombiniert werden und ermöglichen beispielsweise folgende Kombinationen:

  • 10 VMs
  • 10 Workstations
  • 5 VMs + 5 Workstations
  • 5 VMs + 1 Server + 2 Workstations
  • 1 VM + 3 Servers
  • 3 Servers + 1 Workstation

Bei der Free Edition bis Veeam Backup & Replication 9.5 Update 3a war hingegen keine Beschränkung vorhanden. Allerdings kann mit der Free Edition nur VeeamZIP genutzt werden. Ein zeitgesteuertes Backup ist nicht möglich, ebenso können VMs damit nur komplett gesichert werden. Insgesamt ist die neue Community Edition in den meisten Fällen also ein deutlicher Gewinn im Vergleich zur Free Edition.

Darüber hinaus bringt das Update 4 auch einige neue Features mit. Veeam Cloud Tier ist eine weitere Storage-Option und ermöglicht eine Langezeit­archivierung via Amazon S3, Azure Blob Storage oder S3-kompatible Services. Veeam Cloud Mobility ist eine Verbesserung von “Direct Restore to Microsoft Azure”, es werden jetzt auch AWS und Azure Stack als Ziele akzeptiert. Veeam DataLabs ist der Nachfolger für Virtual Labs und bringt ein paar neue Funktionen für das Einrichten einer Testumgebung mit. Des Weiteren lässt sich mit Role-Based Access Control (RBAC) for vSphere der Zugriff auf Backups und Jobs in VMWare regeln und es existieren neue Daten­sicherung-Plugins für SAP HANA und Oracle RMAN.

Einen detaillierten Überblick über alle Neuerungen findet ihr auf dieser Seite.

Download Veeam Backup & Replication 9.5 Update 4

Veeam Backup & Replication Community Edition

36 Jahre alte Sicherheitslücke in SCP gefähredet OpenSSH, PuTTY und Co.

Der Sicherheitsforscher Harry Sintonen hat im Secure Copy Protocol (SCP) mehrere Schwachstellen entdeckt. Dadurch können Angreifer Dateiübertragungen manipulieren und z.B. Schadcode ausführen lassen. Betroffen sind alle Programme, die auf SCP aufsetzen. Die bekanntesten dürften OpenSSH, PuTTY und WinSCP sein.

Mit SCP können Dateien zwischen einem lokalen und einem entfernten Computer sicher über das Netzwerkprotokoll SSH ausgetauscht werden. Sintonen von F-Secure warnt vor fünf Sicherheitslücken in SCP, die teilweise bereits 36 Jahre alt sind. Entdeckt wurden diese allerdings erst im August 2018.

Many scp clients fail to verify if the objects returned by the scp server match those it asked for. This issue dates back to 1983 and rcp, on which scp is based. A separate flaw in the client allows the target directory attributes to be changed arbitrarily. Finally, two vulnerabilities in clients may allow server to spoof the client output.

Konkret könnte sich ein Angreifer über einen Man-in-the-Middle-Angriff in die SSH-Verbindung einklinken und bösartige Dateien einschleusen. So könnten beispielsweise Konfigurationsdateien geändert oder eine bash-Datei im Home-Verzeichnis abgelegt werden.

Nur CVE-2018-20685 ist mit dem Bedrohungsgrad “hoch” eingestuft. Wer auf Nummer sicher gehen möchte, kann vorerst komplett auf SCP verzichten. OpenSSH im SCP-Modus ist von allen Lücken betroffen. In der aktuellen OpenSSH Version 7.9 ist nur die Schwachstelle CVE-2018-20685 behoben. WinSCP ist seit der neuen Version 5.14 komplett abgesichert. Die letzte Version 0.70 von PuTTY wurde Mitte 2017 veröffentlicht und bietet daher noch keinen Schutz.

Raspberry Pi – Ein Blick auf den Stromverbrauch

Raspberry Pi Logo

Der Raspberry Pi kann für eine Vielzahl von Projekten verwendet werden und zeichnet sich durch eine ausreichende Performance und einen geringen Stromverbrauch aus. Doch was bedeutet ein geringer Stromverbrauch genau? Falls der Raspberry Pi mit Akkus betrieben oder als Server verwendet wird und rund um die Uhr läuft, ist es wichtig genaue Werte zu kennen.

Ich habe den aktuellen Raspberry Pi 3B+ genauer unter die Lupe genommen und liefere euch ein paar Werte. Alle Messungen wurden ohne Monitor, Tastatur und Maus durchgeführt. Als Betriebssystem kam das aktuelle Raspbian Stretch Lite (13.11.2018) zum Einsatz.

Raspberry Pi 3B+ Status Stromverbrauch
Idle (kein Ethernet oder WLAN) 1,6 W
Idle (WLAN) 1,9 W
Idle (Ethernet 100 MBit/s) 1,8 W
Idle (Ethernet 1 GBit/s) 2,1 W
Idle (Ethernet 1 GBit/s + WLAN) 2,4 W
stress –cpu 1 (Ethernet 1 GBit/s) 3,2 W
stress –cpu 2 (Ethernet 1 GBit/s) 3,9 W
stress –cpu 3 (Ethernet 1 GBit/s) 4,6 W
stress –cpu 4 (Ethernet 1 GBit/s) 5,2 W

Zusammengefasst benötigt der Raspberry Pi 3B+ im Leerlauf 1,6 Watt. WLAN zusätzlich macht 0,3 Watt aus, LAN je nach Geschwindigkeit 0,2 Watt (100 MBit/s) oder 0,5 Watt (1 GBit/s).

Stromverbrauch minimieren

Insbesondere beim mobilen Einsatz mit Batterien oder Akku ist eine möglichst lange Laufzeit wünschenswert. Mit einigen kleinen Tweaks kann der Stromverbrauch weiter reduziert und damit gleichzeitig die Laufzeit erhöht werden. Nichtsdestotrotz sollte man sich die Frage stellen, ob ein Raspberry Pi Zero W oder ein anderes älteres Modell eine bessere Alternative wären.

HDMI

Wenn kein Bildschirm verwendet wird, kann der HDMI-Port on-the-fly deaktiviert werden:

sudo tvservice -o

Dies spart ca. 20 mA, also 0,1 Watt. Wenn HDMI automatisch deaktiviert werden soll, kann dies z.B. über die “/etc/rc.local” erfolgen. Vor “exit 0” ergänzt man folgendes in der Datei:

# Disable HDMI
/usr/bin/tvservice -o

Eine schönere Alternative ist dies aber über die Datei “/boot/config.txt” zu erledigen:

disable_splash=1
hdmi_blanking=1
hdmi_ignore_hotplug=1
hdmi_ignore_composite=1

Damit die Änderungen aktiv werden ist ein Neustart notwendig.

LEDs

Des Weiteren können die Aktivitäts- und Power-LED deaktiviert werden. Dies geschieht ebenfalls über Einträge in der “/boot/config.txt“:

# Disable the ACT LED.
dtparam=act_led_trigger=none
dtparam=act_led_activelow=off

# Disable the PWR LED.
dtparam=pwr_led_trigger=none
dtparam=pwr_led_activelow=off

Nach einem Neustart lassen sich hier pro LED rund 5 mA sparen, insgesamt also 10 mA oder 0,05 Watt.

Bluetooth & WLAN

Die integrierte WLAN-Funktionalität kann im laufenden Betrieb deaktiviert werden:

sudo ifconfig wlan0 down

Wer WLAN und Bluetooth automatisch immer deaktiviert haben möchte, kann dies wiederrum über die “/boot/config.txt” erledigen:

# Disable Bluetooth and Wifi
dtoverlay=disable-wifi
dtoverlay=disable-bt

Darüber hinaus können nun die Services deaktiviert werden.

# Disable Services
sudo systemctl disable wpa_supplicant.service
sudo systemctl disable hciuart.service
sudo systemctl disable bluealsa.service
sudo systemctl disable bluetooth.service

Da die Services nun deaktiviert sind, werden die entsprechenden Kernelmodule auch nicht mehr benötigt. Diese können über die Datei “/etc/modprobe.d/raspi-blacklist.conf” entfernt werden. Dazu muss folgendes innerhalb der Datei ergänzt werden:

# Disable Bluetooth
blacklist btbcm
blacklist bnep
blacklist bluetooth
 
# Disable Wifi
blacklist 8192cu

USB & Ethernet

Einen wirklich großen Effekt erzielt die Deaktivierung des USB-Chips. Damit lassen sich rund 200 mA, respektive 1 Watt einsparen. Allerdings muss einem bewusst sein, dass damit automatisch auch das Ethernet deaktiviert ist, WLAN funktioniert aber weiterhin.

sudo echo '1-1'|sudo tee /sys/bus/usb/drivers/usb/unbind

Hat das Betriebssystem Einfluss auf den Stromverbrauch?

Angeregt durch einen Kommentar von tux. habe ich mir zudem den Stromverbrauch unter NetBSD / FreeBSD / OpenBSD angesehen. Leider wird der neue Raspberry Pi 3B+ noch nicht von allen BSD-Betriebssystemen vollständig unterstützt, sodass das Gerät nicht automatisch bootet und keine IP-Adresse per DHCP bezieht. In diesem Fall ist die Installation etwas aufwändiger. Abhilfe schafft entweder eine Tastatur und ein Bildschirm oder der Consolen-Zugang mit einem USB to TTL Serial Cable.

NetBSD / FreeBSD

Von NetBSD gibt es ein speziell auf Raspberry Pis angepasstes Image, den Download-Link findet ihr in Zeile 14. Zu beachten ist, dass das integrierte WLAN des Raspberry Pi 3B+ unter BSD aktuell nicht funktioniert.

Bei FreeBSD verwendet ihr am besten FreeBSD-12.0-RELEASE  oder FreeBSD-13.0-CURRENT. Hier gibt es jeweils spezielle Versionen (-RPI3) für den aktuellen Pi, die out-of-the-box laufen. Allerdings funktioniert auch hier das WLAN mangels entsprechendem Treiber nicht.

Raspberry Pi 3B+ Status Raspbian NetBSD FreeBSD
Idle (kein Ethernet oder WLAN) 1,6 W 1,9 W 1,7 W
Idle (Ethernet 100 MBit/s) 1,8 W 2,1 W 1,9 W
Idle (Ethernet 1 GBit/s) 2,1 W 2,5 W 2,2 W

Insgesamt betrachtet liegt der Stromverbrauch unter NetBSD und FreeBSD leicht höher als bei Raspbian.

Weitere Messungen

Alternative Messergebnisse inklusive Vergleichsmessungen zu älteren Raspberry-Pi-Modellen findet ihr bei RasPi.TV und Raspberry Pi Dramble.

Raspberry Pi – Inbetriebnahme und Basisinstallation

Raspberry Pi Logo

Der Raspberry Pi ist wohl der bekannteste und auch beliebteste Einplatinencomputer weltweit. Im Smart Home kommt er oft zum Einsatz, da er für fast alle Projekte genügend Leistung liefert und gleichzeitig einen geringen Stromverbrauch aufweist. In diesem Artikel möchte ich euch zeigen, wie ihr den Raspberry Pi mit einer Basisinstallation bzw. -konfiguration in Betrieb nehmen könnt. Darauf aufbauend lassen sich viele spannende Projekte (unbound, Pi-hole, EDOMI, openHAB, ioBroker, usw.) mit dem kleinen Computer realisieren.

Hardware

Zur Grundausstattung, damit der Raspi in Betrieb genommen werden kann, gehören neben dem Raspberry Pi ein passendes Netzteil und eine Speicherkarte. Ein Bildschirm und eine Tastatur sind im Normalfall nicht notwendig, dazu aber später mehr. Meine Hardwarekomponenten sehen beispielsweise folgendermaßen aus:

Als Alternative zum offiziellen Micro-USB-Netzteil kann selbstverständlich auch ein anderes Netzteil mit 2,5A/5V verwendet werden. Allerdings möchte ich erwähnen, dass es bei USB-Netzteilen bzw. Handyladegeräten teilweise zu Problemen kommt, Stichwort Undervolt-Icon. Das hängt damit zusammen, dass viele Netzteile eine Spannung von 4,9V oder genau 5V am Micro-USB-Stecker liefern. Durch die Bauelemente zur Spannungsregelung auf dem Raspberry Pi führt das aber dazu, dass beim Raspi lediglich 4,7 – 4,8V ankommen, was zu wenig ist. Das offizielle Netzteil liefert am Ausgang 5,1V, wodurch beim Raspi ausreichende 4,9A anliegen. Wer seinen Raspberry Pi 3B+ via PoE betreiben möchte, kann sich den offiziellen PoE-HAT ansehen.

Beim Speicher solltet ihr darauf achten, dass die microSD-Karte den Standard UHS-I unterstützt, sonst bremst ihr euren Pi unnötig aus. Schnellere Karten sind aber auch nicht sinnvoll, da der Minicomputer davon nicht profitiert. Der Speicherplatz sollte mindestens 8 GByte betragen. Bei den aktuellen Preisen, bei denen selbst 32 GByte unter 10 Euro inklusive Versand erhältlich sind, setze ich aber auf mindestens 32 GByte.

Software

Update 08.12.2020: Raspbian Buster in Raspberry Pi OS umbenannt.
Update 06.11.2019: Artikel auf Raspbian Buster angepasst.

Die empfohlene Linux-Distribution für den Raspberry Pi ist Raspberry Pi OS (früher Raspbian). Die aktuelle Version basiert auf Debian 10 Stable (Buster), hat aber einige Anpassungen für den Minicomputer an Bord. Das ist auch der Grund, warum ihr das Betriebssystem immer direkt bei der Raspberry Pi Foundation herunterladen solltet. Raspberry Pi OS ist in drei Varianten erhältlich:

Für viele Projekte genügt das aufs Nötigste reduzierte Raspberry Pi OS Lite. Sofern möglich bevorzuge ich immer die Lite-Variante.

Installation

Mittlerweile empfehle ich die Nutzung des offiziellen Raspberry Pi Imager.

Die Vorstellung des Tools und eine Schritt-für-Schritt-Anleitung mit Screenshots findet ihr hier: Raspberry Pi – Installation mit Raspberr Pi Imager

Die Installation von Raspberry Pi OS auf die microSD-Karte kann mit verschiedenen Methoden durchgeführt werden. Anfänger können auf NOOBS (New Out Of the Box Software) zurückgreifen, welches das gewünschte Betriebssystem vollautomatisch herunterlädt und auf die microSD-Karte packt. Nichtsdestotrotz empfehle ich den “manuellen” Weg, der nicht viel mehr Aufwand bedeutet.

Nach dem Herunterladen der gewünschten Raspberry Pi OS-Version, kann diese unter Windows, Linux oder macOS mit dem Tool Etcher auf die microSD-Karte installiert werden. Das Ganze geht schnell und ist quasi selbsterklärend. Etcher starten, das Raspberry Pi OS -Image- bzw. -ZIP auswählen, anschließend die microSD-Karte angeben und zum Abschuss auf den Button “Flash!” klicken.

Etcher

Alternativ existieren noch weitere Möglichkeiten, die in den offiziellen Anleitungen der Raspberry Pi Foundation beschrieben sind:

Unter Linux und macOS können die Boardmittel genutzt werden. Unter Windows existiert mit dem Tool Win32 Disk Imager eine Alternative zu Etcher, die aber fast identisch funktioniert. Nachdem die Image-Datei und die microSD-Karte als Ziel-Laufwerk angegeben wurden, kann Raspberry Pi OS mit einem Klick auf die microSD-Karte geschrieben werden.

Win32 Disk Imager

Einrichtung / Grundkonfiguration

Nachdem Raspberry Pi OS auf der microSD-Karte installiert wurde, müsst ihr dort auf die Partition “/boot” zugreifen. Unter Windows wird die Boot-Partition als separates Laufwerk angezeigt. Direkt darunter solltet ihr eine neue Datei mit dem Namen “ssh” anlegen. Dies ist notwendig, damit ihr via SSH auf euren Raspberry Pi zugreifen könnt. Das Vorhandensein einer Tastatur und eines Bildschirms ist nicht notwendig.

Grundsätzlich solltet ihr das Gerät wenn möglich via LAN verbinden. Diese Variante ist stabiler als WLAN und bringt niedrigere Latenzzeiten als zusätzlichen Bonus mit. Falls ihr kein LAN nutzen könnt oder einen Raspberry Zero W ohne LAN-Anschluss habt, müsst ihr auf der Boot-Partition noch eine zweite Datei namens “wpa_supplicant.conf” erstellen. Anschließend folgenden Inhalt in die Datei einfügen. Vergesst nicht die SSID und das WLAN-Passwort anzupassen.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=DE
network={
    ssid="<SSID Ihres WLAN>"
    psk="<WLAN-Passwort>"
    key_mgmt=WPA-PSK
}

Im nächsten Schritt steckt ihr eure microSD-Karte in den Raspberry Pi. Anschließend verbindet ihr euren Pi mit dem Netzwerk (bei LAN) und schließt die Stromversorgung an. Innerhalb einer Minute ist der Minicomputer betriebsbereit und sollte via DHCP eine IP-Adresse bekommen haben, sofern in eurem Netzwerk ein DHCP-Server läuft (üblicherweise euer Internet-Router). Dort könnt ihr die vergebene IP einsehen. Bei einer FRITZ!Box findet ihr die benötigte Information unter “Heimnetz –> Netzwerk”. Darüber hinaus sollte das Gerät auch über den Hostnamen “raspberrypi” erreichbar sein.

Jetzt kann die erste Verbindung zum Raspberry Pi via SSH aufgebaut werden. Unter Windows könnt ihr neben PuTTY auch KiTTY oder unter Windows 10 sogar die PowerShell nutzen. Bei Linux oder macOS einfach eine Konsole öffnen und den Befehl “ssh pi@IP-Adresse” verwenden. Die Standard-Zugangsdaten lauten User “pi” und Passwort “raspberry“.

Als Erstes ändert Ihr direkt das Standard-Passwort mit dem Befehl:

passwd

Daraufhin werden das Betriebssystem und die Pakete auf den aktuellen Stand gebracht. Das kann bis zu einer Viertelstunde dauern.

sudo apt update
sudo apt upgrade
sudo rpi-update
sudo apt dist-upgrade

Danach ist euer Raspberry Pi auf dem neuesten Stand und betriebsbereit.

Jetzt könnt ihr mit folgendem Befehl die Grundkonfiguration starten:

sudo raspi-config

Dort lassen sich unter anderem der Hostname, die Sprache, das Tastaturlayout oder die Zeitzone anpassen. Ebenso kann hier das Dateisystem auf die gesamte Größe der SD-Karte ausgedehnt werden.

Dennoch möchte ich euch nachfolgend noch ein paar weitere nützliche Konfigurationen vorstellen.

Statische IPv4-Adresse definieren

In Raspberry Pi OS wird empfohlen, eine IPv4-Konfiguration über den DHCP Client Daemon (DHCPCD) vorzunehmen. Auch wenn der Dienst “dhcpcd” standardmäßig aktiv sein sollte, überprüfen wir zunächst, ob “dhcpcd” läuft:

systemctl status dhcpcd

Der Befehl sollte “dhcpcd” als installiert und aktiv zurückmelden. Anschließend die Datei “/etc/dhcpcd.conf” öffnen:

sudo nano /etc/dhcpcd.conf

Weiter unten in der Datei befindet sich bereits eine beispielhafte Konfiguration für eine statische IP. Dort müsst ihr bei den folgenden vier Zeilen das “‘#” entfernen und die IP-Daten anpassen. Achtet dabei darauf, dass ihr keine IP-Adresse verwendet, die sich im Pool des DHCP-Servers befindet.

interface eth0
static ip_address=192.168.178.100/24
static routers=192.168.178.1
static domain_name_servers=192.168.178.1 8.8.8.8

Nachdem die Änderungen vorgenommen wurden, kann die Datei mit STRG + O gespeichert und mit STRG + X geschlossen werden.

Zum Schluss müssen die Änderungen noch angewandt werden. Da wir via SSH auf den Pi verbunden sind, ist die beste Variante einfach einen Neustart durchzuführen.

sudo reboot

Shell-Konfigurationen

Zum bequemeren Arbeiten können in der “.bashrc” noch weitere Aliase aktiviert werden.

nano ~/.bashrc

Folgende drei Aliase sind bereits vorhanden und müssen lediglich auskommentiert werden:

# some more ls aliases
alias ll='ls -l'
alias la='ls -A'
alias l='ls -CF'

Des Weiteren arbeite ich gerne mit “vim”. Da der Texteditor standardmäßig nicht vorhanden ist, muss dieser nachinstalliert werden:

sudo apt install vim

Anschließend aktiviere ich das Syntax-Highlighting und die Unterstützung für dunklen Hintergrund:

sudo nano /etc/vim/vimrc

Dort bei folgenden zwei Optionen das ” entfernen:

" Vim5 and later versions support syntax highlighting. Uncommenting the next
" line enables syntax highlighting by default.
syntax on

" If using a dark background within the editing area and syntax highlighting
" turn on this option as well
set background=dark

Außerdem ist standardmäßig der “visual mode” aktiviert, welchen ich überhaupt nicht brauchen kann. Dieser kann mit den folgenden zwei Zeilen deaktiviert werden:

set mouse-=a            " Disable mouse usage (all modes)
set term=builtin_ansi

Stromverbrauch verringern

In meinem Artikel “Raspberry Pi – Ein Blick auf den Stromverbrauch” habe ich den Stromverbrauch genauer unter die Lupe genommen. Außerdem habe ich dort einige Tipps aufgeführt, wie ihr den Stromverbrauch verringern könnt.

Firefox 62 – Die Neuerungen

Bereits am 5. September hat Mozilla Firefox 62 veröffentlicht. Die neue Version bietet einige Änderungen und Neuerungen. Wie immer liste ich die wichtigsten nachfolgend auf:

  • Tracking-Schutz ist per Klick auf das Info-Symbol in der Adressleiste erreichbar
    Firefox 62 Trackingschutz
  • Ebenfalls neu: eine Schaltfläche zum Löschen aller Cookies und Websitedaten der aktuell besuchten Webseite
  • Dialog zum Speichern von Lesezeichen zeigt nun Favicon und Vorschau der Webseite
  • mehr Anpassungsmöglichkeiten für die Firefox-Startseite ()
  • nach dem Abmelden von Firefox Sync wird gefragt, ob Daten wie Chronik und Lesezeichen gelöscht oder beibehalten werden sollen
  • Unterstützung für variable Schriften
  • Neue Enterprise Policies
  • weitere kleine Verbesserungen, eine komplette Übersicht aller Änderungen und Neuerungen findet ihr wie immer bei Sören Hentzschel
  • Behebung diverser Sicherheitslücken

Download Firefox 62 (64 Bit)
Portable Firefox @ Horst Scheuer

Firefox 60 – Die Neuerungen

Firefox Logo 57+

Firefox 60 wurde gestern am 09. Mai 2018 veröffentlicht. Neben der normalen Version gibt es auch eine neue ESR-Version (Extended Support Release) mit verlängertem Support. Firefox 60 ESR löst Firefox 52 ESR ab und beinhaltet die Vorzüge der Quantum-Verbesserungen. Darüber hinaus ist die versprochene Policy-Engine enthalten, wodurch sich Firefox besser in Unternehmen einsetzen lassen soll.

  • Policy-Engine zur Verteilung von Unternehmensrichtlinien
  • Firefox-Startbildschirm überarbeitet: weitere Optionen um Ansicht zu individualisieren, responsives Layout, mehr Inhalte auf breiten Bildschirmen, “gesponsorte Inhalte” in US-Version
  • Quantum CSS wird zum Rendern des Browser-UIs genutzt
  • Überarbeitete Ansicht der Optionen zu Cookies und Webseitendaten
  • Unterstützung für das Web-Authentication-API, ermöglicht Authentifizierung an Webseiten mit Hilfe von USB-Tokens (kompatible Hardwaretoken nach FIDO U2F-Konvention sind von Yubikey, Nitrokey oder U2F Zero erhältlich)
  • Symantec-Zertifikate, die vor dem 01.06.2016 ausgestellt worden sind, werden nicht mehr akzeptiert
  • Firefox deaktiviert Webcam und dazugehöriges Licht beim Beenden einer Videoaufnahme
  • Warnhinweise beim Besuch von unverschlüsselten Webseiten im privaten Modus
  • Verbesserte Audioübertragung per WebRTC unter Linux
  • weitere kleine Verbesserungen, eine komplette und sehr ausführliche Übersicht aller Änderungen und Neuerungen findet ihr wie immer auf der Webseite von Sören Hentzschel
  • Behebung diverser Sicherheitslücken

Download Firefox 60 (64 Bit)
Download Firefox 60 ESR (64 Bit)
Portable Firefox @ Horst Scheuer

Firefox 59 – Die Neuerungen

Firefox Logo 57+

Nach dem großen Update auf Firefox 57 und einigen Anpassungen bzw. Verfeinerungen in der folgenden Version 58, geht es Mozilla mit Firefox 59 langsamer an. Firefox 58 wurde gestern am 13. März 2018 veröffentlicht und bietet folgende Neuerungen:

  • Im privaten Modus werden weniger Referrer im HTTP-Header versendet
  • Screenshot-Funktion (in Firefox 56 eingeführt) bietet nun einen Editor mit ein paar grundlegenden Funktionen (Zuschneiden, Zeichen- sowie Textmarker-Werkzeug mit neun Farben)
  • Verfeinerte Kontrolle von Web-Benachrichtigungen
  • “Firefox Health Report” wurde aufgrund zu weniger Nutzer entfernt und die Funktionalität von “about:healthreport” nach “about:telemetry” umgezogen.
  • Auf der neuen Startseite kann die Reihenfolge “Wichtigen Seiten” nun per Drag-and-Drop angepasst werden
  • Neue Startseite soll nun deutlich schneller laden als bisher, wenn viele verschiedene Informationen angezeigt werden
  • Verbessertes Rendering unter macOS dank Off-Main-Thread Painting (OMTP)
  • Neue Suchmaschine “Ecosio” hinzugefügt (nur für Nutzer der deutschsprachigen Version)
  • Suchmaschine Yahoo! für alle Sprachen entfernt
  • Verbesserte Performance dank Race Cache With Network (RCWN) (bei langsamen Cache-Zugriffen wird parallel eine Anfrage an das Netzwerk gesendet und die Quelle genutzt, welche als erstes eine Antwort liefert)
  • Nutzung von TCP Fast Open unter Windows
  • Genauigkeit der Timing-Funktionen auf 2ms reduziert, als Gegenmaßnahme zur CPU-Schwachstelle Spectre (Firefox 57.0.4 hatte die Genauigkeit bereits von 5μs auf 20μs reduziert)
  • Zahlreiche neue Möglichkeiten und Verbesserungen bei WebExtensions
  • viele weitere kleine Verbesserungen, eine komplette Übersicht aller Änderungen und Neuerungen findet ihr wie immer bei Sören Hentzschel
  • Behebung diverser Sicherheitslücken

Download Firefox 59 (64 Bit)
Portable Firefox @ Horst Scheuer