Kategorie: Tutorials

Feintuning Elegoo Neptune 3 Pro / Plus / Max

7. Januar 2023, 12:35 · von Tobi · 10 Kommentare

Seit einigen Wochen besitze ich meinen ersten FDM-3D-Drucker und ich bin wirklich begeistert. Der Drucker bietet ein super Preis-Leistungs-Verhältnis und ist optimal für Einsteiger geeignet. Bei Hartware habe ich einen ausführlichen Testbericht über den Elegoo Neptune 3 Plus verfasst. Auch den Elegoo Neptune 3 Pro habe ich mittlerweile getestet.

Da der Neptune 3 Pro / Plus / Max bis auf die Größe quasi identisch sind, können die beschriebenen Schritte eins zu eins für alle drei Modelle angewendet werden.

Nach dem Aufbau und ein paar grundlegenden Vorarbeiten könnt ihr direkt mit dem ersten Druck starten. Wer bereits mehr Erfahrung im 3D-Druck besitzt, möchte oftmals aber gerne das Feintuning angehen, bevor der erste Druck gestartet wird. Dadurch kann die von Haus aus bereits gute Druckqualität noch weiter gesteigert werden. Das Feintuning kann aber unabhängig davon zu jeder Zeit durchgeführt werden.

Ebenso sollten die nachfolgend genannten Schritte durchgeführt werden, wenn irgendetwas beim Extruder geändert wird (neues Zahnrad, neuer Extruder, neuer Stepper-Motor, etc.).

Extruder steps/mm kalibrieren

Ein wichtiger Punkt beim FDM-Druck ist sicherzustellen, dass der Extruder tatsächlich die gewünschte Menge an Filament fördert. Im Fachjargon spricht man von “Extruder steps/mm kalibrieren”. Mit diesen Stichworten solltet ihr im Internet diverse ausführliche Anleitungen finden. Ich gehe nur im Schnelldurchlauf darauf ein.

Zunächst muss der 3D-Drucker mit einem PC oder Notebook verbunden werden. Das mitgelieferte USB-Kabel beim Neptune 3 Pro ist mit 50 cm leider sehr kurz. Entweder stellt ihr euer Notebook direkt neben den Drucker oder ihr verwendet ein längeres USB-Kabel bzw. eine USB-Verlängerung. Anschließend kann der auf der microSD-Karte vorhandene USB-Treiber installiert werden. Dieser kann aber auch hier heruntergeladen werden (CH341SER.EXE): http://www.wch-ic.com/downloads/CH341SER_ZIP.html

Ebenso benötigt ihr das Tool “Pronterface”, welches ihr bei Github herunterladen könnt.

Nach dem Start von Pronterface könnt ihr oben links den richtigen COM-Port auswählen und auf “Connect” klicken.

Anschließend ladet ihr ein Filament eurer Wahl in den Extruder und markiert dann 12 cm. 12 cm nehmen wir deshalb, damit wir auch nachmessen können, wenn zu viel eingezogen wurde. Wenn wir nur 10 cm markieren, würde das nicht funktionieren.

Die Temperatur muss passend zum verwendeten Filament gesetzt werden. Jetzt könnt ihr über den Touchscreen 100 mm extrudieren lassen.

Elegoo Neptune 3 Plus – Load 100mm

Wenn das erledigt ist, könnt ihr nachmessen, wie viel Filament eingezogen wurde. Wenn es annähernd 10 cm sind (+- 2-3 mm), dann ist alles in Ordnung. Sollten es beispielsweise 9 oder 11 cm gewesen sein, solltet ihr die steps/mm anpassen. Bei mir wurden nur 9,2 cm eingezogen.

Der aktuelle Wert kann via Pronterface mittels des Befehls “M503” ausgelesen werden. Gesucht ist der Wert “M92”. In meinem Fall war das Ergebnis “M92 X80.00 Y80.00 Z400.00 E390.00”. Also 390 Steps. Mit Hilfe des Dreisatzes könnt ihr nun den neuen Wert berechnen: 100 x (alter Wert) / (neuer Wert) = X. In meinem Beispiel also 100 x 390 / 92 = 423,91.

Ich habe auf 424 aufgerundet und den neuen Wert mit dem Befehl “M92 E435” an den Drucker gesendet. Mit “M500” wird alles gespeichert und mit “M503” kann man die Anpassung nochmals überprüfen.

Zum Schluss solltet ihr die genannten Schritte wiederholen und nochmals prüfen, ob jetzt genau 10 cm extrudiert werden.

Temperatur-Tower

Nachdem die hardwareseitige Kalibrierung passt, kommen wir zu den Filament-Einstellungen. Als erstes müssen wir die optimale Drucktemperatur herausfinden. Damit das klappt nutzen wir einen sogenannten Temperatur-Tower. Bei Thingiverse gibt es verschiedene Modelle, wobei sich unter anderem diese Variante mit fertigem GCODE bewährt hat: https://www.thingiverse.com/thing:3912855

Nach dem Druck wählt ihr die am besten aussehende Temperatur. Mit dieser Temperatur werden alle weiteren Schritte durchgeführt. Dabei solltet ihr auf minimales Stringing, ein minimales Durchhängen an Brücken und Überhängen und generell auf ein insgesamt “gutes Aussehen” wert legen.

Flow anpassen

Kommen wir zur Einstellung der Flowrate bzw. Flussrate (in Deutsch). Um die richtige Flowrate herauszufinden, nutzen wir den Würfeltest. Hierzu drucken wir einen 20×20 mm Würfel ohne Infill, ohne Top und Bottom-Layer und mit einer Wandstärke, welche dem doppelten Nozzle-Durchmesser entspricht. Beim Standard-Nozzle mit 0,4 mm drucken wir also zwei Wände mit jeweils 0,4 mm, was dann 0,8 mm ergibt.

Ich nutze immer folgendes Modell: https://www.thingiverse.com/thing:38108

Nach dem Druck wird mit dem Messschieber gemessen. Dabei solltet ihr nicht in der Nähe der Ecken messen, da hier die Werte abweichen können. Des Weiteren sollten auch nicht die ersten paar Schichten mit gemessen werden, Stichwort “Elefantenfuß”. Messt am besten alle vier Wände und bildet dann den Durchschnitt. Sollte der Wert nicht genau 0,8 mm ergeben, müsst ihr entsprechend die Flowrate anpassen. Hier die benötigte Formel:

neue Flowrate = (erwartete Dicke / gemessene Dicke) x (aktuelle Flowrate)

Wenn die Messung also beispielsweise 0,85 mm ergibt, dann lautet die Rechnung so: (0,8 / 0,85) x 100 % = 94,12 %

Den neuen Flow-Wert könnt ihr nur in eurem Slicer eintragen. In Cura befindet sich die entsprechende Einstellung unter “Material”.

Abschließend wird der Würfel mit der angepassten Flussrate erneut gedruckt und gemessen.

PID-Autotuning am Hotend

Eine relativ einfache, aber wirkungsvolle Möglichkeit, die Druckergebnisse zu optimieren ist das sogenannte PID-Autotuning. Das Kalibrierungsverfahren sorgt dafür, dass die Temperatur am Hotend möglichst stabil bleibt und nicht zu stark schwankt.

Der Elegoo Neptune 3 Pro / Plus / Max unterstützen das PID-Autotuning mit der ausgelieferten Firmware allerdings noch nicht. Bevor die Funktion zum Einsatz kommen kann, muss also die Firmware aktualisiert werden. Die jeweils aktuellste Firmware und eine kurze Anleitung findet ihr bei Github:

https://github.com/NARUTOfzr/Neptune_3_Pro_Plus_Max

Sobald das erledigt ist, kann das PID-Autotuning starten. Hierzu müsst ihr wieder Pronterface starten und euch mit eurem Drucker verbinden.

Mit dem Befehl “M503” könnt ihr die aktuelle Einstellung auslesen. Der gesuchte Wert befindet sich bei “M301”. Bei meinem Drucker war “M301 P24.50 I1.80 D79.42” hinterlegt.

Anschließend könnt ihr das PID-Autotuning starten. Die Zieltemperatur sollte im Idealfall die Temperatur sein, mit welcher ihr am häufigsten druckt. Da ich das meiste mit Extrudr NX2 PLA drucke, sind dies bei mir 215 °C. Ebenfalls drucke ich immer mit eingeschaltetem Lüfter, daher sollte das Tuning auch mit Lüfter erfolgen. Also starten wir zunächst den Lüfter mit dem Befehl “M106 E0 S255”. Anschließend kann das Tuning in meinem Beispiel mit dem Befehl “M303 E0 S215 C10” gestartet werden. 10 ist die Anzahl der Heizzyklen. Das Hotend wird jetzt zehnmal auf 215 °C aufgeheizt und wieder abgekühlt. Währenddessen werden die optimalen Werte ermittelt, die am Ende des Tunings ausgegeben werden.

Die drei umrandeten Werte sind die ermittelten Idealwerte. Diese übernehmen wir in den Befehl “M301” und senden diesen ab: M301 P42.11 I6.27 D70.75

Jetzt wird die Konfiguration mit “M500” gespeichert.

Quellen:

https://www.reddit.com/r/ender3/comments/ec2i9j/how_to_calibrate_your_printers_esteps_and/
https://drucktipps3d.de/extruder-esteps-kalibrieren/
https://drucktipps3d.de/fluss-und-linienbreite-einstellen/

Kategorien: Hardware Privat Tutorials

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

9. Dezember 2022, 10:31 · von Tobi · 17 Kommentare

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

Adobe Acrobat Reader DC – Werkzeugleiste komplett und dauerhaft entfernen

8. August 2022, 17:46 · von Tobi · 4 Kommentare

Der Adobe Acrobat Reader DC zeigt standardmäßig eine Seitenleiste auf der rechten Seite an. Im Programm wird diese als “Werkzeugleiste” bezeichnet. Viele Nutzer empfinden diese Werkzeugleiste als sehr nervig, da sie im Arbeitsbereich wertvollen Platz einnimmt. Die Leiste kann unter anderem mit “Shift + F4” minimiert werden. Allerdings wird diese beim nächsten Öffnen des Programms automatisch wieder angezeigt.

Adobe Acrobat Reader DC Werkzeugleiste

In meinem früheren Artikel “Adobe Acrobat Reader DC Seitenleiste entfernen” habe ich bereits beschrieben, wir ihr das Verhalte ändern könnt, sodass die Leiste im minimierten Zustand verbleibt.

Wer die Werkzeugleiste jedoch niemals benötigt, der kann sie auch dauerhaft loswerden. Das ist sogar einfacher als gedacht.

Dauerhafte Ausblendung der Werkzeugleiste via Registry

Mit Hilfe der Registry kann die Werkzeugleiste automatisch via GPO ausgeblendet werden. Dazu bitte die Registry öffnen und zu folgendem Registrierungsschlüssel navigieren:

HKEY_CURRENT_USER\SOFTWARE\Adobe\Adobe Acrobat\DC\AVGeneral

Hier muss der Wert “aDefaultRHPViewMode_L” auf “Collapsed” gesetzt werden. Ebenso muss der Wert “bRHPSticky” auf 1 gesetzt sein.

Dauerhafte Entfernung der Werkzeugleiste

Für die permanente Entfernung muss ein Plugin im Installationsverzeichnis vom Adobe Acrobat Reader DC gelöscht bzw. umbenannt werden. Es handelt sich um die Datei “Viewer.aapp” in folgendem Ordner:

C:\Program Files\Adobe\Acrobat DC\Acrobat\RdrApp\DEU\

Je nach Installation und Sprache kann das Verzeichnis leicht variieren. Sobald die Datei umbenannt oder gelöscht ist und das Programm gestartet wird, ist die Werkzeugleiste komplett verschwunden. Auf die Funktionsweise der einzelnen Komponenten wie z. B. “Kommentieren”, “Messen” oder “Zertifikate” hat die Entfernung keinerlei Auswirkungen. Alles funktioniert wie gewohnt.

Die Vorgehensweise lässt sich auch automatisieren, sodass in Unternehmensnetzwerken alle Geräte von der entfernten Werkzeugleiste profitieren können. Hier kann die entsprechende Datei einfach via Gruppenrichtlinie oder Intune-Regel umbenannt oder gelöscht werden. Alternativ lässt sich das Ganze auch direkt beim Deployment regeln. Ein anderer Ansatz wäre den Zugriff auf die Datei via NTFS-ACL zu verbieten. Wie ihr sehen könnt, sind hier viele Möglichkeiten gegeben.

Kategorien: Software & Apps Tutorials Windows

Proxmox Host SSD tauschen / clonen und vergrößern

24. Juli 2022, 18:09 · von Tobi · 3 Kommentare

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.

Inhalt entsperren

Mehr Informationen

Kategorien: Linux Tutorials

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

5. Mai 2022, 22:43 · von Tobi · 4 Kommentare

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

3. Mai 2022, 15:50 · von Tobi · 9 Kommentare

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

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

20. September 2021, 22:56 · von Tobi · 11 Kommentare

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

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

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

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

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.).

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

Kategorien: Hardware Linux Software & Apps Tutorials

AVM FRITZ!Box 5530 Fiber am Telekom-FTTH-Anschluss in Betrieb nehmen

16. Februar 2021, 09:58 · von Tobi · 18 Kommentare

Die neue FRITZ!Box 5530 Fiber wurde bereits im September 2019 das erste mal gezeigt. Mehr als ein Jahr später, Mitte November 2020, fand die offizielle Vorstellung statt. Als Verkaufsstart nannte AVM hier lediglich “demnächst verfügbar”. Anschließend hat es nochmal ca. zwei Monate gedauert, bis die FRITZ!Box 5530 Fiber das erste Mal käuflich zu erwerben war. Seitdem sind immer mal wieder Angebote bei Amazon zu finden, die in der Regel aber nach wenigen Stunden ausverkauft sind.

Ich hatte Glück und konnte letzte Woche eine 5530 ergattern, die vor wenigen Tagen bei mir eingetroffen ist. Nachdem ich bereits von einigen Firmware-Problemen bei der offiziellen FRITZ!OS Version 07.21 gelesen hatte, habe ich ohne weitere Tests direkt zur neuesten erhältlichen Firmware gegriffen. Zum Zeitpunkt des Artikels war das FRITZ!OS 07.24-86065 Inhaus. Den Download findet ihr übrigens hier: https://download.avm.de/inhaus/PSQ19Phase2/5530/FRITZ.Box_5530-07.24-86065-Inhaus.image

Und hier ist die neue FRITZ.Box_5530-07.24-86375-Inhaus.

Telekom-Setup

Bereits seit einigen Jahren werden bei uns in der Gegend Neubaugebiete mit Fiber to the Home (FTTH) ausgestattet. Die Telekom setzt dabei auf Gigabit Passive Optical Network (GPON).

Die Beantragung erfolgt über den Netzversorger. Dieser legt dann in koordinierter Bauweise neben dem Strom- unter anderem auch den FTTH-Anschluss in die Mehrspartenhauseinführung. Genauer gesagt erst einmal nur das Glasfaserleerrohr. Anschließend wird die Glasfaser eingeblasen und der Glasfaser-Abschlusspunkt (Gf-AP) gesetzt. Üblicherweise wird daneben die Glasfaser-Teilnehmeranschlussdose (Gf-TA) verbaut. Diese kann aber z.B. auch in einem anderen Raum oder im EG verbaut werden. Als drittes wird der die Optical Network Termination (ONT) platziert. Dabei handelt es sich schlicht und einfach um das Glasfasermodem welches via LC-Simplex-Patchkabel mit der Gf-TA verbunden wird. Die FTTH-Grundinstallation bei der Telekom ist also Gf-AP –> Gf-TA –> ONT.

Bei mir kommt ein sogenannter Klapp-TA zum Einsatz. Dabei handelt es sich um einen Gf-TA der sich aufklappen lässt mit integriertem ONT. Ich habe ein Leerrohr von der Mehrspartenhauseinführung zum Netzwerkschrank gelegt, sodass ich den kombinierten Gf-TA/ONT dort platzieren konnte. In meinem Fall ist der ONT ein Huawei EchoLife HG8010u (ONT v3). Dieser besitzt eine LAN-Schnittstelle, welche man mit dem Router verbindet, in meinem Fall eine ältere FRITZ!Box 7490.

Nachfolgend ein paar Fotos:

: Telekom FTTH Mehrspartenhausanschluss und Gf-AP

: Telekom FTTH Gf-AP

: Telekom FTTH Klapp-TA mit ONT

Umstellung auf FRITZ!Box 5530 Fiber

Mein Ziel war es, den ONT und die ältere FRITZ!Box 7490 durch die neue FRITZ!Box 5530 Fiber zu ersetzen. Einfach Umstecken funktioniert allerdings nicht, da hier einige Dinge zu beachten sind. Nachfolgend eine kleine Anleitung, die bei mir und anderen Benutzern einwandfrei funktioniert hat.

Als Ausgangssituation startet ihr mit eurem aktiven und verbundenen ONT (Glasfaserkabel ist eingesteckt).
Zunächst benötigt ihr die ONT-Kennung, welche ihr bei der Telekom erfragen müsst. Theoretisch funktioniert das über die Hotline. Praktisch wissen nur wenige Ansprechpartner Bescheid, weshalb ihr vermutlich mehrmals anrufen müsst, bis euch die ONT-Kennung genannt wird. Daher würde ich euch empfehlen die Anfrage via “Telekom hilft” auf Twitter zu stellen. Das funktioniert zuverlässig und vermutlich auch schneller.
Wie anfangs beschrieben solltet ihr eure FRITZ!Box 5530 auf die neueste Version aktualisieren.
Nun könnt ihr das GPON-Modul in eure 5530 stecken, das Glasfaserkabel vom ONT entfernen und mit eurer FRITZ!Box verbinden.
Die Seite “http://fritz.box/support.lua” öffnen, einloggen und ganz runter scrollen. Dort bei “GPON Seriennummer” die Seriennummer eures ONTs eintragen. Mit dem Klick auf den Button “Einstellungen übernehmen” hat es bei mir komischerweise nicht funktioniert. Daher habe ich nach dem Eintragen oben links auf das FRITZ!-Logo geklickt und im Popup auf “Übernehmen”.

Die Seriennummer bei den Huawei-ONTs findet ihr unter dem Deckel. Diese könnt ihr 1:1 übernehmen.
Bei älteren Sercomm-ONTs müsst ihr die Seriennummer erst umwandeln. Als Hilfestellung kann ich diesen Forenbeitrag empfehlen.

FRITZ!Box 5530 GPON-Seriennummer

FRITZ!Box 5530 GPON-Seriennummer
Anschließend unter “http://fritz.box” die Telekom-Zugangsdaten und die ONT-Kennung eintragen.
FRITZ!Box 5530 Zugangsdaten
Optional: Ab sofort könnt ihr ohne weiteres Zutun zwischen FRITZ!Box 5530 und altem ONT wechseln. Einfach das Glasfaserkabel umstecken.

Sollte bei euch diese Variante nicht funktionieren, gäbe es noch die Möglichkeit über einen Rediscover. In diesem Fall müsst ihr die Seriennummer eures Telekom-ONTs nicht übernehmen. Nachteil dieser Methode ist allerdings, dass ab sofort nur noch die FRITZ!Box 5530 an eurem FTTH-Anschluss funktioniert. Ein Wechsel zurück zum alten ONT hätte einen erneuten Rediscover zur Folge. Da diese Variante einige Nachteile besitzt hier nur die Kurzform:

ONT-Kennung bei der Telekom erfragen. Funktioniert sporadisch via Hotline, daher besser “Telekom hilft”.
FRITZ!Box 5530 auf die neueste Version aktualisieren.
Glasfaserkabel vom ONT entfernen.
Bei der Telekom einen Rediscover anfordern. Funktioniert sporadisch via Hotline, daher besser “Telekom hilft”.
Glasfaserkabel in das GPON-Modul der FRITZ!Box 5530 stecken und Zugangsdaten eintragen.

Kategorien: Hardware Internet Netzwerk Tutorials

Ubiquiti UniFi Dream Machine Pro (UDM-PRO) – NAT deaktivieren

7. Februar 2021, 09:01 · von Tobi · 151 Kommentare

Die Ubiquiti UniFi Dream Machine Pro (UDM-PRO) bietet ein gutes Preis-Leistungs-Verhältnis, weshalb sie oft im Privatgebrauch oder in kleinen Firmen zum Einsatz kommt. Idealerweise wird das Gerät direkt oder über ein Modem mit dem Internet verbunden. Hierfür stehen an der UDM-PRO die beiden WAN-Ports 9 (RJ45) und 10 (SFP) zur Verfügung. Auf beiden Ports ist die Network Address Translation (NAT) standardmäßig aktiviert. Innerhalb der Konfigurationsoberfläche besteht keine Möglichkeit NAT zu deaktivieren.

Falls die UDM-PRO unter bestimmten Voraussetzungen hinter einem Router, z.B. einer FRITZ!Box betrieben werden muss, dann hat man zwangsweise den Nachteil von doppeltem NAT. In vielen Fällen kann dieses Setup ohne weitere Einschränkungen genutzt werden. Doppeltes NAT führt aber oftmals bei Onlinespielen, Xbox, PlayStation und Co zu Problemen. Diese Probleme können jedoch behoben werden, indem die UDM-PRO in der FRITZ!Box als “Exposed Host” konfiguriert wird. Das doppelte NAT ist dann aber trotzdem noch vorhanden.

Lange Rede kurzer Sinn: In diesem Artikel möchte ich euch zeigen, wie ihr NAT auf den WAN-Ports der UDM-PRO deaktivieren könnt.

SSH aktivieren und verbinden

Zunächst müsst ihr den SSH-Zugang aktivieren und ein Passwort setzen. Dies erfolgt über die Einstellungen der UDM-PRO unter dem Punkt “Console Settings”. Bei älteren Versionen von UniFi OS sieht die Weboberfläche ein wenig anders aus.

UDM SSH aktivieren

Anschließend könnt ihr euch z.B. mit PuTTY via SSH auf die UDM-PRO verbinden. Der Username ist “root”.

Mit folgendem Befehl können wir die aktuelle NAT-Konfiguration einsehen:

ab UniFi OS 3.x:
xtables-multi iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK -v --line-number
UniFi OS 2.x und älter:
xtables-legacy-multi iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK -v --line-number

Standardmäßig sieht die NAT-Konfiguration folgendermaßen aus:

Chain UBIOS_POSTROUTING_USER_HOOK (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1     481K   66M MASQUERADE  all  --  any    eth8    anywhere             anywhere   
2        0     0 MASQUERADE  all  --  any    eth9    anywhere             anywhere

Hier ist ersichtlich, dass auf Port 9 (eth8) und Port 10 (eth9) NAT aktiviert ist.

“UDM / UDMPro Boot Script” installieren

Voraussetzung für das Deaktivieren von NAT ist das “UDM / UDMPro Boot Script“, welches auch nach einem Neustart oder Firmwareupdate bestehen bleibt.

Für die Installation wird das Boot Script heruntergeladen und installiert. Je nach Version von UniFi OS kann noch die alte Version des Skripts verwendet werden, welche bis UniFi OS 2.4.x funktionieren sollte.

curl -fsL "https://raw.githubusercontent.com/unifi-utilities/unifios-utilities/HEAD/on-boot-script/remote_install.sh" | /bin/sh

Alternativ ab UniFi OS 2.5.x und höher dann folgende Variante. Hier ist etwas mehr manuelle Handarbeit zu erledigen:

# Download package
curl -L https://github.com/unifi-utilities/unifios-utilities/raw/main/on-boot-script-2.x/packages/udm-boot-2x_1.0.1_all.deb -o /tmp/udm-boot-2x_1.0.1_all.deb

# Install it
dpkg -i /tmp/udm-boot-2x_1.0.1_all.deb

# Patches for 'udm-boot-2x_1.0.1_all.deb' package
sed -i 's/Description=Run On Startup UDM 2.x/Description=Run On Startup UDM 3.x/g' /lib/systemd/system/udm-boot.service
sed -i '/Restart=on-failure/d' /lib/systemd/system/udm-boot.service
sed -i '/RestartSec=5s/d' /lib/systemd/system/udm-boot.service

# Enable reload and start
systemctl enable udm-boot
systemctl daemon-reload
systemctl start udm-boot

Zum Schluss sollte geprüft werden, ob das Skript auch läuft:

systemctl status udm-boot.service

Sofern “Run On Startup UDM 3.x” angezeigt wird, passt alles.

NAT deaktivieren

Jetzt könnt ihr eigene Shell Scripte in “/data/on_boot.d” hinterlegen, die bei jedem UDM-PRO Start bzw. Reboot ausgeführt werden.

cd /data/on_boot.d

Dort erstellt ihr euer Skript zur Deaktivierung von NAT:

touch /data/on_boot.d/delete-nat.sh

Das Skript funktioniert ab UniFi OS 3.x und bekommt folgenden Inhalt:

#!/bin/bash
# Check if script runs directly after boot. If so, wait for 10 seconds.
uptimeMinutes=`cat /proc/uptime | awk '{print $1}'`
if [ ${uptimeMinutes::-3} -lt 300 ]
	then
		logger NAT-Script: Script zum 1. Mal nach Boot ausgefuehrt
		sleep 10
	else
		logger NAT-Script: Script via Cron-Job ausgefuehrt
fi

# Check if default NAT rules exist
if iptables -t nat -S UBIOS_POSTROUTING_USER_HOOK | grep -e "UBIOS_POSTROUTING_USER_HOOK -o eth8 -m comment --comment 00" -e "UBIOS_POSTROUTING_USER_HOOK -o eth9 -m comment --comment 00" > /dev/null
	then
		xtables-legacy-multi iptables -t nat -D UBIOS_POSTROUTING_USER_HOOK 1
		if iptables -t nat -S UBIOS_POSTROUTING_USER_HOOK | grep -e "UBIOS_POSTROUTING_USER_HOOK -o eth8 -m comment --comment 00" -e "UBIOS_POSTROUTING_USER_HOOK -o eth9 -m comment --comment 00" > /dev/null
			then
				xtables-legacy-multi iptables -t nat -D UBIOS_POSTROUTING_USER_HOOK 1
				if iptables -t nat -S UBIOS_POSTROUTING_USER_HOOK | grep -e "UBIOS_POSTROUTING_USER_HOOK -o eth8 -m comment --comment 00" -e "UBIOS_POSTROUTING_USER_HOOK -o eth9 -m comment --comment 00" > /dev/null
					then
						logger NAT-Script: NAT-Regel gefunden, Loeschen nicht erfolgreich \(Fehler!\)
					else
						logger NAT-Script: NAT-Regel gefunden und geloescht
				fi
			else
				logger NAT-Script: NAT-Regel gefunden und geloescht
		fi
	else
		logger NAT-Script: Keine NAT-Regel vorhanden
fi


# Check if cron job exists
if ls /etc/cron.d/delete-nat > /dev/null 2>&1
	then 
		logger NAT-Script: Cron-Job vorhanden
	else
		echo "*/15 * * * * /data/on_boot.d/delete-nat.sh" > /etc/cron.d/delete-nat
		logger NAT-Script: Cron-Job nicht vorhanden und erstellt
		/etc/init.d/cron restart 
fi

Das Skript ist eine leicht optimierte Version der ursprünglichen Variante aus dem Kommentar von other_tobi.

Es überprüft, ob die standardmäßig gesetzten NAT-Regeln vorhanden sind und entfernt diese. Außerdem wird ein rudimentäres Logging geboten.

Bei jeder Änderung im Routing oder in den Firewall-Regeln der UDM-PRO werden die beiden NAT-Policies wiederhergestellt. Aus diesem Grund wird ein Cronjob erstellt, welcher dafür sorgt, dass das Skript alle 15 Minuten ausgeführt wird. Somit wird sichergestellt, dass die Standard-NAT-Regeln wieder entfernt werden, sofern diese automatisch generiert werden.

Das Skript muss anschließend noch ausführbar gemacht werden:

chmod +x delete-nat.sh

Bei Bedarf könnt ihr das Skript direkt starten und prüfen, ob es funktioniert.

bash delete-nat.sh

Eine Überprüfung mit

xtables-legacy-multi iptables -t nat -L UBIOS_POSTROUTING_USER_HOOK -v --line-number

zeigt, dass beide NAT-Regeln entfernt wurden:

Chain UBIOS_POSTROUTING_USER_HOOK (1 references)
num pkts bytes target prot opt in out source destination

Das Logging des Skripts könnt ihr folgendermaßen einsehen:

grep NAT /var/log/messages

Statische Route in der FRITZ!Box

Standardmäßig ist das FRITZ!Box Subnetz 192.168.178.0/24 und das Netz der UDM-PRO 192.168.1.0/24.

Damit Clients aus dem UDM-PRO-Subnetz auf das Internet oder die FRITZ!Box zugreifen können, wird noch eine statische Route auf der FRITZ!Box benötigt.

Diese könnt ihr unter “Heimnetz –> Netzwerke –> Netzwerkeinstellungen” anlegen. Dazu ganz nach unten scrollen und auf den Button “IPv4-Routen” klicken (siehe Bild).

Dort erstellt ihr eine neue Route und gebt folgende Daten ein:

Netzwerk: das Netz der UDM-PRO, standardmäßig 192.168.1.0
Subnetzmaske: die Subnetzmaske des vorher eingetragenen Netzes, standardmäßig 255.255.255.0
Gateway: die Adresse der UDM-PRO im FRITZ!Box Subnetz, diese kann unter “Heimnetzwerk” in Erfahrung gebracht werden

Mit Klick auf “Übernehmen” ist dieser Schritt erledigt.

Optional: Firewall-Regel in der UDM-PRO

Dieser Schritt ist nur notwendig, wenn ihr vom Subnetz der FRITZ!Box auf ein Subnetz “hinter” der UniFi Dream Machine Pro zugreifen möchtet. Anders herum funktioniert es ohne weitere Konfiguration.

Die Kommunikation wird nämlich noch durch die Firewall der UDM-PRO blockiert. Um dies zu ändern, muss eine neue Regel erstellt werden. Zunächst muss der UniFi Network Controller auf der UDM-PRO geöffnet werden. Anschließend unter “Einstellungen –> Security –> Internet Threat Management –> Firewall” auf den Button “Create new Rule” klicken.

Exemplarisch habe ich jeglichen Traffic aus dem Subnetz der FRITZ!Box freigegeben. Sofern möglich solltet ihr die Freigabe jedoch spezifischer gestalten, z.B. auf einzelne IP-Adressen einschränken und nicht ganze Subnetze freigeben.

Kategorien: Hardware Internet Netzwerk Tutorials

Raspberry Pi – Installation mit Raspberry Pi Imager

10. Januar 2021, 18:55 · von Tobi · 0 Kommentare

Es existieren verschiedene Möglichkeiten, um ein Betriebssystem für den Raspberry Pi auf eine microSD-Karte zu installieren. In der Vergangeheit habe ich dafür immer Etcher verwendet. Seitens Raspberry Pi wurde aber mittlerweile der Raspberry Pi Imager ins Rennen geschickt, welchen ich euch absolut ans Herz legen kann. Dieser steht auf der offiziellen Webseite zum Download bereit. Das Open-Source-Tool ist für Windows, macOS und Ubuntu verfügbar. Den Quellcode findet ihr bei GitHub.

Ein großer Vorteil des Raspberry Pi Imager ist, dass dieser automatisch alle unterstützten Betriebssysteme auflistet und direkt on-the-fly während dem Download auf die microSD-Karte schiebt. Nachfolgend eine kurze Übersicht, wie die einzelnen der Schritte der Installation aussehen.

Nach der Installation von Raspberry Pi Imager könnt ihr das Tool direkt starten.
Als erstes wählt ihr das gewünschte Betriebssystem aus. Ich empfehle grundsätzlich immer Raspberry Pi OS Lite, sofern nichts dagegen spricht.
Anschließend muss die microSD-Karte für die Installation gewählt werden. Bei mir habe ich das Image testweise auf einen USB-Stick installiert, also nicht wundern.
Vor dem Start erscheint eine Warnung dass alle Daten gelöscht werden, die ihr mit “JA” bestätigen müsst.
Anschließend beginnt der Download des gewählten Images, welches on-the-fly auf die microSD-Karte geschrieben wird.
Sobald der Schreibvorgang beendet ist, erhaltet ihr eine Bestätigung.

Kategorien: Hardware Software & Apps Tutorials Windows

Raspberry Pi – Installation und Betrieb von WireGuard

9. April 2020, 23:35 · von Tobi · 46 Kommentare

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.

: WireGuard Android App – QR-Code scannen

: WireGuard Android App – Tunnel Name vergeben

: WireGuard Android App – Tunnel Infos

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.

: WireGuard Android App – Tunnel Einstellungen bearbeiten

: WireGuard Android App – Bestimmte Apps ausschließen

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/

Kategorien: Hardware Linux Netzwerk Software & Apps Tutorials

User Profile Wizard: Lokales Windows-Benutzerprofil zu Domäne migrieren

15. Dezember 2019, 21:31 · von Tobi · 0 Kommentare

Mit dem Tool User Profile Wizard von ForensiT lassen sich lokale Benutzerprofile unter Windows mit wenigen Klicks zu einer Domäne migrieren. Des Weiteren ist mit dem Tool auch die Übernahme von Benutzerprofilen von einer Domäne zu einer anderen möglich.

Ich habe das Tool vor zig Jahren das erste Mal erfolgreich eingesetzt. Erst kürzlich hatte ich es erneut gebraucht, jedoch erst nach längerer Suche wiedergefunden. Wie bei der ersten Nutzung konnte ich damit einige lokale Windows-Profile blitzschnell und ohne Probleme in ein Domänenprofil umwandeln. Der große Vorteil ist, dass sämtliche Daten, Programme und Einstellungen erhalten bleiben.

User Profile Wizard ist unter Windows 7, Windows 8(.1) und Windows 10 funktionstüchtig. Folgende Schritte sind zur Migration eines Userprofils notwendig.

User Profile Wizard mit Adminrechten starten und Willkommens-Dialog bestätigen
Das gewünschte Benutzerprofil markieren und auf “Weiter” klicken, die weiteren Optionen zur Deaktivierung bzw. Löschung des lokalen Profils würde ich zur Sicherheit nach erfolgreicher Migration von Hand vornehmen.
Die neue Domäne und den Domänenuser eintragen und sicherstellen, dass der Punkt “Join Domain” aktiviert ist
Jetzt müsst ihr lediglich noch die Anmeldedaten des Domänen-Benutzers eingeben und die Migration des Benutzerprofils startet.
Nach kurzer Zeit ist der Vorgang beendet. Mit einem Neustart werden alle Änderungen aktiv.

Neben der Personal-Edition existieren zwei weitere, kostenpflichtige Versionen (Professional Edition und Corporate Edition) mit einem größeren Funktionsumfang. Eine Vergleichstabelle liefert eine detaillierte Auflistung der Unterschiede. Größtenteils handelt es sich aber um Automatisierungsfunktionen, die erst bei einer größeren Menge von umzustellenden Profilen wichtig sind. Für einige wenige Profile seid ihr mit der Personal-Edition bestens gerüstet!

Kategorien: Software & Apps Tutorials Windows Windows 10 Windows 7 Windows 8

VPN-Installation über den privaten Internetrouter

27. November 2019, 10:52 · von Tobi · 1 Kommentare

Ganz unabhängig davon, ob Sie privat unterwegs sind oder für ein Unternehmen im Außendienst arbeiten, die Sicherheit Ihrer Daten hat für Sie sicherlich die höchste Priorität. Oftmals wird diese begleitet von dem Wunsch, von überall aus ins Internet zu gehen – selbst wenn der Zugriff zum Internet nicht abgesichert ist und es durchaus passieren kann, dass die Daten, die über eben dieses ungesicherte Netz übertragen werden, während der Übertragung korrumpiert werden könnten.

Um das Risiko des Hackings der Daten ausschließen zu können, sollten Sie ein „Virtuelles Privates Netzwerk“ bzw. englisch „Virtual Private Network“ (VPN) einrichten. Dabei handelt es sich um ein in sich geschlossenes Netzwerk, zu dem lediglich bestimmte Personen Zugriff erhalten, beispielsweise Außendienstmitarbeiter oder Handelsvertreter. Aber auch Privatleute nutzen die Qualitäten des VPNs immer häufiger, in dem sie ihr eigenes Heimnetzwerk besonders schützen. Dazu wird eine VPN-Software auf den Client – zumeist ein Smartphone oder Tablet – aufgespielt und darüber mit dem VPN-Server des Anbieters verbunden. Zwischen beiden Geräten wird ein VPN-Tunnel zum sicheren Datentransfer aufgebaut, durch den die Daten verschlüsselt gesendet werden und von außen nicht einsehbar sind. Parallel dazu wird die IP-Adresse des Clients durch die des VPN-Servers ersetzt, sodass eine Zuordnung des Datenzugriffs nicht mehr nachvollziehbar ist.

Vorrangig wird ein VPN eingesetzt, um anonym auf Internetinhalte zugreifen zu können und die eigene Privatsphäre zu schützen. Da der Transfer aller Daten verschlüsselt erfolgt, lassen sich Versender und Empfänger nur sehr schwierig zurückverfolgen.

Die eigene Fritzbox zum VPN-Tunnel umfunktionieren

AVM FRITZ!Box 7490

Für Privatleute, die eine FritzBox des Herstellers AVM im Einsatz haben, können gleich mehrfach durch den Umbau zu einem VPN-Server profitieren. Um die FritzBox für das VPN einzurichten, müssen Sie die folgenden Schritte durchführen:

Aktivieren Sie per Klick auf die Punkte rechts oben die „Erweiterte Ansicht“.
Klicken Sie auf „Internet“ und auf Ihr „MyFRITZ!-Konto“.
Existiert ein „MyFRITZ!-Konto“ bereits, geht es mit Schritt 11 weiter. Sonst wählen Sie „Neues MyFRITZ!-Konto erstellen“, geben Sie Ihre E-Mail-Adresse ein und gehen Sie auf „Weiter“.
AVM sendet Ihnen nun eine E-Mail. In ihr ist ein Link enthalten, um Ihre „FritzBox! Registrieren“ und auf der folgenden Webseite auf „MyFRITZ!-Konto einrichten“.
Geben Sie auf den Feldern „Kennwort“ und „Kennwort bestätigen“ ein neues, noch nicht gebrauchtes Kennwort ein.
Klicken Sie auf „Vorgang abschließen“.
Gehen Sie zurück zur FritzBox und klicken Sie dort auf „MyFRITZ!-Internetzugriff einrichten“ und „FRITZ!Box-Benutzer einrichten“. War MyFRITZ bereits eingerichtet, klicken Sie im „System“ auf „FRITZ!Box-Benutzer“.
Nun können Sie alle Benutzer einrichten, die später Zugriff auf den FritzBox-VPN-Server erhalten sollen. Jeder Besucher ist mit Benutzername und einem einzigartigen Passwort einzurichten. Besteht schon ein FritzBox-Benutzer für den Zugriff, aktivieren Sie den Stift daneben.
Stellen Sie sicher, dass sowohl die Option „Zugang aus dem Internet erlaubt“ als auch die Option „VPN“ aktiviert sind.
Die E-Mail-Adresse bleibt unverändert und klicken Sie auf „OK“.
Die FRITZ!Box meldet sich nun automatisch bei MyFRITZ! an. Der Hinweis „Ihre FRITZBox ist bei MyFRITZ! angemeldet“, eventuell unter der Option Internet oder im MyFritz!-Konto.
Notieren Sie sich die Zeichenfolge bei „(Ihrer) MyFRITZ!-Adresse“.
Klicken Sie auf „Heimnetz“, „Netzwerk“, „Netzwerkeinstellungen“ und „IPv4-Adressen“.
Stellen Sie sicher, dass bei der „IPv4-Adressen“ nicht die Standardadresse 192.168.178.0 steht, sondern tragen Sie stattdessen eine Alternative wie 192.168.178.1 ein und klicken anschließend auf OK.
Warten Sie, bis sich der PC wieder mit der FritzBox verbunden hat.

Fernzugriff auf die eigene FritzBox

Die FritzBox von AVM bieten eine unvergleichliche Funktionsvielfalt und ermöglichen es zusätzlich, dass für einen sicheren Fernzugriff auf das Heimnetzwerk, beispielsweise, wenn ein Familienmitglied unterwegs und die Wahrscheinlichkeit eines Zugriffs über eine ungesicherte WLAN-Schnittstelle hoch ist. Neben den oben genannten Einstellungen am Router selbst müssen auch Änderungen an den digitalen Endgeräten vorgenommen werden, wobei die Art des Gerätes und die Software eine Rolle spielt.

Kategorien: Internet Tutorials

Raspberry Pi – SSH Hardening

24. November 2019, 22:50 · von Tobi · 2 Kommentare

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

Kategorien: Hardware Linux Software & Apps Tutorials

Custom ROM auf Xiaomi Smartphones installieren

24. August 2019, 11:35 · von Tobi · 11 Kommentare

Nach rund einem Jahr mit dem Xiaomi Redmi Note 5 stand bei mir ein Smartphone-Wechsel an. Da ich unbedingt ein kompakteres Smartphone haben wollte, bin ich schlussendlich beim Xiaomi Mi 9 SE gelandet. Zähneknirschend habe ich den relativ kleinen Akku (3.070 mAh) und die fehlende Benachrichtigungs-LED akzeptiert. Ein Smartphone, welches zu 100 Prozent alle gewünschten Features beinhaltet und gleichzeitig noch halbwegs erschwinglich ist, existiert sowieso nicht ;-)

In den letzten Wochen wurden die ersten Custom ROMs für das Xiaomi Mi 9 SE veröffentlicht und die gravierendsten Probleme behoben. Nachdem beim Remi Note 5 der Support für LineageOS eingestellt wurde, habe ich mich kurzerhand dazu entschlossen, anderen ROMs eine Chance zu geben. Für das Mi 9 SE existieren aktuell sowieso noch nicht viele Alternativen, weshalb ich mich für crDroid entschieden habe. crDroid basiert auf AOSP bzw. LineageOS , bringt aber zusätzliche Anpassungsmöglichkeiten aus einigen anderen ROMs mit.

Nachfolgend möchte ich kurz das Vorgehen beschreiben, wie ihr auf ein neues Smartphone von Xiaomi eine beliebige Custom ROM bekommt. Wie oben bereits erwähnt, beziehe ich mich dabei auf crDroid und das Mi 9 SE. Das Vorgehen sollte aber bis auf kleine Anpassungen für alle neuen Xiaomi-Smartphones und für viele andere Custom ROMs gültig sein.

Bootloader entsperren

Zunächst muss der Bootloader eures Xiaomi-Smartphones entsperrt werden. Denkt daran, dass dabei all eure Daten auf dem Smartphone gelöscht werden. Wer das Gerät also bereits genutzt hat, sollte vorher dem Entsperren des Bootloaders ein Backup anfertigen.

Hier die einzelnen Schritte zum Bootloader Entsperren in einer kurzen Übersicht:

Voraussetzung ist ein funktionierendes “adb” und “fastboot”. Empfehlen kann ich den 15 seconds ADB Installer.
Mi-Account erstellen und mit diesem auf dem Smartphone anmelden. Unter MIUI 10 funktioniert das folgendermaßen:
1. Einstellungen -> Mein Gerät
2. Mehrmals auf den Punkt “MIUI-Version” klicken, bis die Entwickleroptionen freigeschaltet werden.
3. Dann zu “Einstellungen” -> “Kategorie System & Gerät -> Weitere Einstellungen” -> “Entwickleroptionen”.
4. Unter “Mi Entsperr-Status”mit eurem Mi-Account einloggen.
Ab diesem Zeitpunkt beginnt die Wartezeit, welche bis zu 360 Stunden (15 Tage) betragen kann. Bei mir waren es erfreulicherweise nur 7 Tage. Wie lange es bei euch dauert, seht ihr im nächsten Schritt.
Mi Unlock Tool downloaden (neueste Version direkt von Xiaomi).
Mi Unlock Tool starten. Anschließend mit eurem Mi-Account anmelden.
Smartphone ausschalten, per USB mit eurem PC verbinden und in den Fastboot-Modus starten (volume down und Power-Taste gleichzeitig drücken).
Versuchen das Smartphone zu entsperren. Jetzt sollte euch die Wartezeit angezeigt werden.
Nach der Wartezeit erneut mit Schritt 5 beginnen. Solltet ihr einen Fehler bekommen, könnt ihr evtl. auch eine ältere Version des Mi Unlock Tools probieren. Bei mir hatte die neueste Version nicht funktioniert, Version 2.3.803.10 aber problemlos.
Mi Unlock

Custom Recovery (TWRP) installieren

Sobald der Bootloader entsperrt ist, muss im zweiten Schritt das Custom Recovery TWRP (Team Win Recovery Project) installiert werden. Die aktuelle TWRP-Version für euer Gerät findet ihr entweder direkt auf der TWRP-Homepage oder im xda-Forum.

Smartphone im Fastboot-Modus starten (volume down und Power-Taste gleichzeitig drücken) und via USB mit eurem PC verbinden.
Prüfen ob das Gerät korrekt erkannt wird:
```
fastboot devices
```
TWRP-Recovery flashen. Der erste Befehl ist nur notwendig, wenn euer TWRP in einem separaten Ordner liegt.
```
cd C:\Users\USERNAME\Desktop
fastboot flash recovery twrp-3.3.1-7a-Mi9SE.img
```
Auf keinen Fall “fastboot boot …” nutzen, da ansonsten die Verschlüsselung beschädigt wird und ihr zur Reparatur “data” neu formatieren müsstet.
TWRP-Recovery booten (volume up und Power-Taste gleichzeitig drücken) und warten bis TWRP geladen ist.
Modifizierung des Dateisystems erlauben.

Custom ROM installieren

Zwei Drittel sind schon geschafft, jetzt folgt das Flashen der Custom ROM (in meinem Fall crDroid) und Co. Zunächst müsst ihr ein paar Downloads tätigen und die Dateien auf das Smartphone legen. Das Kopieren auf das Smartphone sollte auch direkt unter TWRP funktionieren.

Firmware: Xiaomi Firmware Updater
Custom ROM: crDroid 5.7
Google Apps (optional): Open GApps (pico)
Root (optional): Magisk
Kernel (optional): Kowalski Kernel oder Okitavera’s Kernel

Jetzt könnt ihr loslegen.

In TWRP Recovery booten (volume up und Power-Taste gleichzeitig drücken).
Im Recovery den Punkt “Wipe“ aufrufen, dann den Button “Format Data” klicken. Anschließend “Swipe to Factory Reset ausführen” und erneut in TWRP Recovery booten.
Neue Firmware installieren, dabei müsst ihr auf eine kompatible Version achten, Stichwort Anti-Rollback. Wenn das Custom ROM keine vendor.img enthält, müsst ihr diese zusätzlich installieren.
Custom ROM (crDroid) installieren.
Open GApps installieren.
Smartphone neustarten (Reboot –> System).*
ROM einrichten.
Erneut in TWRP Recovery booten.
Root (Magisk) und ggf. Kernel installieren.
Smartphone neustarten (Reboot –> System).
(optional) Magisk Manager einrichten.

*Bei einem Boot-Loop muss eine weitere Datei (vbmeta.img) via Fastboot geflasht werden, um den Loop zu beheben.

fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img

Kategorien: Android Hardware Smartphones Tutorials

Kategorie: Tutorials

Extruder steps/mm kalibrieren

Temperatur-Tower

Flow anpassen

PID-Autotuning am Hotend

Quellen:

Umsetzung

Dauerhafte Ausblendung der Werkzeugleiste via Registry

Dauerhafte Entfernung der Werkzeugleiste

Partition vergrößern

Physical Volume vergrößern

Logical Volume vergrößern

Quellen

Manuelle Variante

Automatisches Skript

Raspberry Pi aktuell halten

Docker Installation

Portainer Installation

Portainer verwenden

Portainer aktualisieren

Telekom-Setup

Umstellung auf FRITZ!Box 5530 Fiber

SSH aktivieren und verbinden

“UDM / UDMPro Boot Script” installieren

NAT deaktivieren

Statische Route in der FRITZ!Box

Optional: Firewall-Regel in der UDM-PRO

WireGuard Installation

Generierung der benötigten Schlüsselpaare

WireGuard Server Konfiguration erstellen

WireGuard Client Konfiguration erstellen

WireGuard Server starten

WireGuard Client unter Android einrichten

Troubleshooting

Quellen

Die eigene Fritzbox zum VPN-Tunnel umfunktionieren

Fernzugriff auf die eigene FritzBox

Grundlagen und hilfreiche Befehle

SSH-Server: Einstellungen

SSH-Server: Cipher-Suites und Verschlüsselungsalgorithmen

Bootloader entsperren

Custom Recovery (TWRP) installieren

Custom ROM installieren

Mich unterstützen

Werbepartner

Neueste Kommentare