Es ist egal wie oft man ein Backup macht und auch dessen Wiederherstellung testet – es gibt immer den Moment, in dem ein Restore versagt …. Und das immer dann, wenn man es am wenigsten brauchen kann.

Im konkreten Fall hat die Festplatte des Laptops meiner Schwiegermutter den Geist aufgegeben und es wurde dafür eine kleinere SSD verbaut.
Es gab nur 1 Backup, nämlich das nach der Installation des Laptops vor ca. einem 3/4 Jahr, welches über das Windows-Systemabbild erzeugt wurde.
Jedoch ließ sich dieses Systemabbild nicht mehr Wiederherstellen.
Ständig kann der Fehler, dass der Zugriff verweigert ist, obwohl bereits alle Dateirechte angepasst wurden und alle Zugriffe über den Explorer auf alle Dateien gegeben war.
Sogar die Bereitstellung des Backups über eine Samba-Freigabe mit einem Linux-Live-System, hat immer den Fehler der Dateiberechtigung gebracht (was macht man nicht alles in der Not).
Es war schier zum Verzweifeln.

Glück im Unglück:
Jetzt zeigte sich der Vorteil des Windows-Systemabbildes. Es legt sein Abbild als vhd-Datei – also als virtuelle Festplatte – ab..
Dadurch ist es möglich diese Backup-Dateien zu mounten und als normales Laufwerk anzusprechen (was auch möglich war – ohne Fehlermeldung bezüglich Dateirechte ….).
Nun stellt sich die Frage: Wie bekomme ich die Dateien wieder zu einem funktionierenden System auf die neue Festplatte/SSD?
Retter in der Not war hier das Programm „Minitool Partition Wizard“, welches auch als nicht installierbare, portable, Version gibt. Damit kann man nicht nur Partitionen verändern, sondern auch kopieren.
Um das Problem nachzustellen, hier der Testaufbau:
Als „Recovery-Computer“ fungiert ein unabhängiger Rechner mit
– einem lauffähigen System (in diesem Fall ein Windows-8-Rechner),
– das portable Programm „Minitool Partition Wizard“,
– die neue Festplatte für den defekten Rechner (hier ein 120GB große Festplatte) über USB-Adapter
– und eine externe USB-Festplatte mit dem Systemabbild.
Um die Daten aus dem Systemabbild zu übernehmen musste ich die Bootpartition aus dem Abbild mounten und auf die neue Festplatte kopieren. Danach musste dann die Systempartition aus dem Abbild gemountet werden und ebenfalls auf die neue Festplatte kopiert werden, welche aber kleiner war als die ursprüngliche Festplatte. Deshalb war ein Verkleinern der Systempartition in der virtuellen Festplatte notwendig.
Aber der Reihe nach.
Die folgenden Artikel beschreiben:
Das Erstellen eines Windows-Systemabbildes
Eine reguläre Wiederherstellung eines Windows-Systemabbildes
Das Desaster mit einem Windows-Systemabbild (und der rettenden Schritte)

Es gibt eine Vielzahl von Backupsystemen für Windowsrechner – egal ob lokal installiert oder als Server-Client-System, egal ob kostenlos oder kostenpflichtig.
Und es gibt Backupmechanismen, die bereits mit dem Windows ausgeliefert werden: z.B.: die Systemabbildsicherung.

Die Aufgabe der Systemabbildsicherung ist es ein komplettes Backup einer Festplatte zu erstellen, um ein funktionierendes und eingerichtetes System, z.B.: nach einem Festplattencrash, wiederherstellen zu können – ohne Rücksicht auf gespeicherte User-Daten (sozusagen ein Desaster Recovery).
Da ein solches Abbild die gesamten Festplattendaten enthält, ist es weniger dafür geeignet, Daten zu sichern, sondern (wie der Name schon sagt) ein komplettes System zu sichern.
Solche Sicherungen werden in einem längeren Abstand ausgeführt, als eine Datensicherung, da sie sehr große Datenmengen beinhalten können. Die Hauptaufgabe eines Systemabbildes ist das „schnelle“ Wiederherstellen eines komplett gecrashten Systems und nicht die Wiederherstellung von einzelnen Dateien oder Verzeichnissen.

Systemabbild erstellen (GUI)

Die Wege zu Systemabbilderstellung über die GUI ist bei den Windowsversionen unterschiedlich.
Win7 Systemsteuerung -> System und Sicherheit -> Sichern und Wiederherstellen links oben auf „Systemabbild erstellen“ klicken

Win 8 Systemsteuerung -> System und Sicherheit -> Dateiversionsverlauf unten links auf „Systemabbildsicherung“ klicken

Win10 Systemsteuerung -> System und Sicherheit -> Sichern und Wiederherstellen (Windows 7) links oben auf „Systemabbild erstellen“ klicken

Ab hier sind die Dialoge wieder gleich.

Man wählt ein Ziellaufwerk aus. In diesem Beispiel eine externe Festplatte, man könnte aber auch eine DVD oder ein Netzlaufwerk angeben.
Schon kann sie Sicherung beginnen

Systemabbild erstellen (wbadmin)

Den Windows-Versionen 7/8/10 gemein ist der Commandline-Befehl „wbadmin“.
Der Befehl für das Starten eines Systemabbildes benötigt einige Parameter.
Dazu gehören das Ziellaufwerk, die Datenquellen und die Art der zu sichernden Daten.
Das Ziellaufwerk wird mit „-backuptarget“ angegeben (in diesem Fall das USB-Laufwerk „E:“
Die Datenquelle ist das Laufwerk „C:“
Möchte man alle Dateien inkl. Deren Dateihistorie sichern, so benutzt man den Parameter –vssFull. Möchte man hingegen nur die aktuelle Version der Daten sichern, nutzt man „-vssCopy“ (was auch der Standardwert ist)
Man kann Systemdateien auch auf andere Partitionen auslagern. Möchte man, dass alle ,für das System relevante, Dateien gesichert werden, gibt man den Parameter „-allCritical“ an. Somit wird auch die Boot-Partition mit gesichert.
Der Parameter „-quiet“ schützt vor „nervigen“ Nachfragen

wbadmin start backup -backupTarget:E: -include:C: -vssFull -allCritical –quiet

Ist das Backup beendet, findet man auf dem Sicherungslaufwerk den Ordner „WindowsImageBackup“

Systemreparaturdatenträger:

Um das Backup wieder herstellen zu können, benötigt man entweder einen Systemreparaturdatenträger, oder die Installations-CD des aktuellen Systems.
Man kann nicht mit einer Installations-CD mit Windows 7 ein Backup von einem Windows 10 Rechner wiederherstellen, oder umgekehrt. Es kann sogar Probleme geben, ein Windows Enterprise mit einer Windows Professional Installations-CD wiederherzustellen. Deshalb empfiehlt es sich, zu einem Backup immer auch einen Reparaturdatenträger zu erstellen, dass die Systemstände zueinander passen.

Das Problem ist lediglich, dass ein DVD-RW-Laufwerk vorausgesetzt wird. Ist kein DVD-RW vorhanden, kann man evtl. noch mit virtuellen DVD-Brennern den Datenträger erstellen (z.B.: Total Mounter von Kernsafe.com).

Möchte man ein Systemabbild wiederherstellen, so bootet man vom zuvor erstellen Reparatur-Datenträger oder von der Windows-Installations-CD.

Nutzt man die Installations-CD, so muss man die Computer-Reparatur-Optionen auswählen.
In den Menüoptionen wählt man die „Problembehandlung“ aus und hier die Systemimage-Wiederherstellung.
Beispiel Windows 7

Beispiel Windows 10

Danach wählt man das wiederherzustellende Betriebssystem aus (in diesem Fall Windows 10).

Ab jetzt ist die GUI wieder Systemübergreifend gleich:
Ist der Datenträger mit dem Backup verfügbar, wird automatisch das letzte, für dieses System passende, Backup als Auswahl angeboten.

Möchte man einen anderen Backupstand auswählen, kann man dies über die Option „Systemabbild auswählen“ veranlassen.
Mit „Weiter“ kommt man zum nächsten Schritt
Die Option „Datenträger formatieren und neu Partitionieren“ löscht alle Daten auf der Festplatte und erzeugt die Partitionen/das Dateisystem komplett neu.

Die Auswahl nochmal bestätigen und das Backup startet

Wenn das Backup fertigist, startet der Rechner neu durch.

Und das System ist wiederhergestellt.

Im aktuellen Fall war leider ein reguläres Wiederherstellen des Systemabbildes nicht möglich, weshalb ich das System mit Hilfe der vhd-Dateien manuell wiederhergestellt habe. Retter in der Not war für mich das kostenfreie Tool „Minitool Partition Wizard“.

Folgende Schritte wurden an einem unabhängigen Rechner mit Windows 8 ausgeführt, an dem zusätzlich die neue Festplatte (120GB) und der Backupdatenträger mit dem Windows-Systemabbild, angeschlossen war.

Schritt 1: Mounten der Boot-vhd

Um Zugriff auf die Dateien des Systemabbildes zu bekommen, müssen erst die Zugriffsrechteerlangt werden. Dies kann durch das System erfolgen, oder man macht es manuell über den Reiter „Sicherheit“ der Datei-Eigenschaften. Im eigentlichen Backup-Verzeichnis sind dann mehrere Dateien, von denen für dieses Beispiel nur die vhdx-Dateien von Bedeutung sind.

Zuerst muss die Bootpartition vom Windows Backup kopiert werden.
In unserem Fall ist es die Datei b6d883ad-0000-0000-0000-100000000000.vdhx

Eingebunden wird die virtuelle Festplatte z.B.: über diskpart.
Der Befehl zum Einbinden lautet:

select vdisk file=“E:\WindowsImageBackup\DESKTOP-KV073KP\Backup 2017-10-12 080847\b6d883ad-0000-0000-0000-100000000000.vdhx”

und

attach vdisk

ab jetzt ist die Festplatte im System eingebunden.

Schritt 2 Kopieren der Bootpartition

Jetzt starte ich das „Minitool Partition Wizard“ und sehe hier nun mehrere Festplatten.
Wichtig ist für mich, als Quelllaufwerk, die eingebundene virtuelle Festplatte und das 120GB große Ziellaufwerk

Sollte das Ziellaufwerk eine Partition besitzen, so lösche ich diese jetzt

Jetzt kopiere ich die 500MB große Bootpartition auf das Ziellaufwerk

Damit die Aktion auch ausgeführt wird, bestätige ich das mit „Apply“

Schritt 3: mounten der System-vhd

Um nun die Systempartition zu kopieren, unmounte ich zuerst die virtuelle „Boot“-Disk. Grundsätzlich müsste ich das nicht machen, da man mehrere virtuelle Festplatten mounten kann, aber damit es übersichtlich bleibt, mach ich diesen Zwischenschritt.
Der Befehl lautet
Detach vdisk

Jetzt wähle ich die virtuelle „System“-Disk aus dem Backup aus und mounte diese mit dem Befehl:

select vdisk file=“E:\WindowsImageBackup\DESKTOP-KV073KP\Backup 2017-10-12 080847\b6d883ad-0000-0000-0000-501f00000000.vdhx”

und

attach vdisk

Nach einem erneuten Einlesen der Festplatten im „Minitool Partition Wizard“, erkennt man die eingebundene virtuelle Festplatte

Schritt 4: Verkleinern der Partition

Da die ursprüngliche Festplatte 180GB hatte, passt diese nun nicht auf die neue, kleinere, Festplatte.
Dazu muss man die Partition verkleinern.
Grundsätzlich geht das auch mit dem Diskpart-Befehl „Shrink“, jedoch kann Diskpart die reservierten Bereiche von Dateien (z.B.: Pagefile.sys oder Schattenkopiebereich) nicht verkleinern.
Deshalb nehme ich auch hier wieder das „Minitool Partition Wizard“ um die Partition in der virtuellen Festplatte zu verkleinern.

Hinweis:

Sollte sich die virtuelle Festplatte nicht genug verkleinern lassen, weil z.B.: viele Dateien darauf sind (Musik Bilder), könnte man die Vdisk noch in das System einbinden (Befehle) und die Dateien auf eine externe Festplatte verschieben, so dass genug Platz für die Verkleinerung vorhanden ist.

Schritt 5: Kopieren der Systempartition

Jetzt kann ich, wie unter Schritt 2, die Systempartition auf das Ziellaufwerk kopieren.

Hier kann ich auch gleich wieder auswählen, wie groß die Partition sein soll (anpassen an Plattenplatz). Vermutlich hätte ich in diesem Schritt auch eine zu große Partition verkleinern lassen können, aber ich mache es lieber Step by Step.

Schritt 6: Partitionen korrigieren

Als nächstes kontrollieren wir den Partitionstyp. Da es sich um ein MBR-System handelt sollten die Boot- und Systempartition als „Primary“ gesetzt werden.

Die Boot-Partition muss zusätzlich noch als „Aktiv“ gesetzt werden.

Und nicht vergessen, auf „Apply“ klicken um die Aktionen auch auszuführen.

Jetzt habe ich beide Partitionen wieder auf einer neuen, physischen, Platte und kann diese nun in den Laptop/Rechner einbauen.

Schritt 7: Bootsektor reparieren

Nach dem die Festplatte im Rechner eingebaut ist und der Rechner gestartet wird, endet der erste Start sehr wahrscheinlich in einem Fehler.

Da sich die Partitionen geändert haben, muss die Bootroutine/der Bootsektor repariert werden.
Dazu starte ich noch einmal die Reparatur-/Installations-CD mit den Reparaturoptionen.

Unter Problembehandlung -> Eingabeaufforderung kann man eine Konsole öffnen ….

…und folgende Befehle eingeben.

Bootrec /fixmbr
Bootrec /fixboot
Bootrec /rebuildbcd

Der Befehl „/bootrec /rebuildbcd“ bringt als Auswahl alle gefundenen Windowssysteme, welche eingebunden werden können. Da in diesem Beispiel nur ein System vorhanden war, wird auch nur eines angezeigt, welches mit „J“ (Ja) oder „A“ (alle) bestätigt werden kann.
Mit dem Befehl Exit beendet man die Konsole und kann nun den Rechner neu starten.

Der Rechner sollte nun ohne Probleme starten.

Ein Aufruf des Diskmanagements zeigt nun die Festplatte mit (in diesem Fall) 120GB Größe an.

Es hat also geklappt, ein nicht wiederherstellbares Systemabbild, welches von einer 180GB großen Festplatte gemacht wurde, auf eine kleinere Festplatte, funktionsfähig, zu kopieren.
Man kann vom Windows-Systemabbild halten, was man will – ich finde es ganz ok. Und im Gegensatz zu anderen Softwarepaketen, bekommt man hier eine virtuelle Festplatte (vhd), welche man im Notfall auch anderweitig wiederhergestellt bekommt.

Möchte man einen Rechner neu installieren, hat man meistens das Problem alle Treiber zu finden. Speziell bei älterer Hardware kann es durchaus etwas schwierig werden, die passenden Treiber zu finden. Hat man bereits ein laufendes System, kann man sich mit folgendem Trick helfen.

Schritt 1: Treiber exportieren
Der schnellste Weg an die benötigten Treiber zu kommen, ist der Export aus einem laufenden System.
Dies kann man seit Windows 10 einfach mit dem Befehl „DISM“ ausführen.

dism /online /export-driver /destination:c:\_treiber

Hierbei werden alle benötigten Treiber in das Verzeichnis „C:\_treiber“ exportiert.
Eine Ausgabe könnte so aussehen:

Nach dem der Export erfolgt ist, sollte der Inhalt des Ordners „C:\_treiber“ ähnlich so aussehen:

Diesen Ordner sollte man jetzt auf einen externen Datenträger sichern.
Kleiner Hinweis:
Der Ordner kann auch mehrere Gigabyte an Daten enthalten.

Schritt 2: Treiber importieren (rekursiv)
Der Export wird so auch auf vielen Webseiten beschrieben – der Import wird aber meist so erklärt, dass man im Gerätemanager auf das jeweils nicht erkannte Gerät klickt und „Update Treiber“ auswählt (wobei man dann auf das lokale-Verzeichnis des Exports verweist).

Kann man so machen – aber es ist halt langwierig.

Besser ist es, alle Treiber auf einmal zu importieren.
Dazu nutze ich den Befehl „PNPUTIL.EXE“

pnputil.exe /add-driver d:\Driver6570b\*.inf /subdirs /install

In diesem Fall habe ich das Verzeichnis mit den Treibern so benannt, wie der Gerätetyp heißt (hier HP Probook 6570b).
Mit „*.inf“ werden alle Treiber installiert. Der Parameter „/subdirs“ sorgt dafür, dass dies rekursiv über alle Unterverzeichnisse des Pfades erfolgt.
„/install“ führt die Installation aus.
Den, ebenfalls verfügbaren, Parameter „/reboot“ habe ich weg gelassen, damit nicht während oder nach der Installation automatisch ein Neustart ausgeführt wird.
Eine Ausgabe könnte so aussehen:

Sollte ein Treiber einen Neustart benötigen. so wird dies zwar angezeigt, aber nicht ausgeführt.

Nach einer Weile sollte das Ergebnis dann so aussehen:

Zusätzlicher Hinweis
Man kann mit dem PNPUTIL-Befehl jegliche Treiber über deren „.inf“-Dateien installieren, so dass man nicht zwingend erst einen DISM-Export machen muss.
Bei Windows 7 funktioniert z.B. der DISM-Befehl nicht. Hier kann man den Ordner „C:\Windows\System32\DRIVERSTORE“ sichern und dennoch wie oben die Treiber rekursiv wieder installieren.
Gleiches funktioniert auch mit Depolyment-Paketen der Hersteller (meist unter dem Begriff „SCCM“ angeboten).
Ich nutze dies auch um Geräte aktuell zu halten. Bietet mir ein Hersteller ein aktuelles Treiber-Paket an, welches mehrere Setups enthält, installiere ich diese nicht einzeln über die jeweiligen unattend-Parameter, sondern ebenfalls über den „PNPUTIL“-Befehl.

Da mein RaspberryPi 1 und mein BananaPi schon etwas in die Jahre gekommen sind, wollte ich mir eigentlich den aktuellen RaspberryPi 4 kaufen um wieder ein Gerät zum Herumspielen zu haben.
Ein Set kostet aber so um die 100 Euro und es zwängt sich die Frage auf: brauche ich wirklich einen Raspberry, wenn ich die GPIO’s nicht nutze?

Oder vielleicht doch besser einen Barebone Rechner, mit dem man dann virtualisiert?
Ein Intel Nuc (als Beispiel) kostet aber locker mal das 3fache.
Ich bin dann auf eine Rohe&Schwarz Gateprotect Firewall gestoßen.
Diese Firewall besitzt ein Board der Firma Lanner (FW-7543) und ist entweder mit einem Intel Atom E3800 (Variante A) oder einem Intel Celeron J1900 (Variante B) bestückt.
Ich konnte über ebay ein Firewall der Variante B für ca 60 Euro ergattern.

Im Lieferumfang war

• Die Firewall (FW-7543B)
• Netzteil
• 19“ Montagebügel
• Halterung für das Netzteil
• Serial -> RJ45 Kabel

 

Was mir besonders gut gefällt sind die 4 Netzwerkkarten, da beim Virtualisieren hier direkt auch auf ein Interface zugegriffen werden kann – bzw. ich für jedes Interface eine eigene Bridge erzeugen könnte.
Da es sich bei mir vorwiegend um ein Spielzeug zum ausprobieren handelt, kann man damit auch externe Router/switche/Vlan’s austesten und muss nicht über eine Schnittstelle gehen.
Abgesehen davon könnte man natürlich auch eine eigene Firewall damit betrieben (OPNsense, IPFire, Fli4l, smoothwall … und wie sie alle heißen).

Als die Firewall bei mir eintraf, ging es gleich mal an’s Ausprobieren.
Erster Hürde: das Gerät hat keinen Video-Ausgang.
Also habe ich die Firewall erstmal aufgeschraubt und siehe da – es gäbe einen VGA-Ausgang als Steckerleiste, jedoch wurde dieser nicht herausgeführt.
Leider hatte ich auch kein passendes Kabel zur Hand, weshalb ich hier erstmal nicht weiter probierte.
Ich fand auch einen Stecker für weitere USB-Anschlüsse, die ich wohl auch noch erweitern werde. So könnte man dann intern 2 weitere USB-Sticks oder USB-Sata-Adapter mit weiteren SSD’s anhängen.
Ein weiterer Wehrmutstropfen ist die eingebaute SSD und der Ram.
Die Firewall besitzt 4GB Ram, was erstmal nicht üppig ist, er könnte aber – laut Datenblatt – wohl auf 8GB erweitert werden.
Die SSD hat nur 32GB – aber immerhin ist es eine SSD und nicht irgend ein lahmer SD-Speicher.
Die SSD kann natürlich durch eine handelsübliche SSD ersetzt werden.

Was mir auch gut gefällt ist der Anschluss vom Netzteil. Dieser ist verschraubt und kann somit nicht versehentlich ausgesteckt werden.
Das Gehäuse ist sehr stabil, was man auch am Gewicht merkt.
Die CPU ist passiv gekühlt. Am Gehäuse ist jedoch ein kleiner Lüfter verbaut.
Dieser läuft beim Einschalten kurzzeitig auf Volllast (inkl. dementsprechender Geräuschkulisse), wird dann aber herunter geregelt und wird fast unhörbar – zumindest in normaler Umgebung (im Schlafzimmer würde ich ihn jedoch nicht betreiben wollen).
Kurzum: man merkt deutlich, dass es sich um ein „Profi“-Gerät für den Dauereinsatz handelt.
Aber das Teil möchte ja auch genutzt werden.
Im nächsten Schritt dann das mitgelieferte Serial RJ45 Kabel angeschlossen, ein Terminal-Programm auf die Serielle Schnittstelle (115000 bps) lauschen lassen und los geht’s.
Während sich Arch-Linux ohne Probleme installieren ließ (serielle Konsole war bis zum Grub per default aktiv und man muss nur noch einen Boot-Parameter angeben) und beim OpenmediaVault-Installations-Medium grundsätzlich die serielle Schnittstelle aktiv ist, war es bei Debian nötig das Installations-Medium für die Nutzung der seriellen Konsole anzupassen.
Aber davon soll mein nächster Beitrag handeln.

Nach dem Begutachten der Hardware ist es nun an der Zeit, ein System zu installieren.
Für den ersten Step fällt meine Entscheidung auf ein Debian 11.
Allerdings müssen am Bootmedium einige Änderungen vorgenommen werden: Die Ausgabe auf die serielle Konsole muss aktiviert werden.

Dazu habe ich mit dem Tool „Rufus“ die Debian 11 Netinst-Cd auf einen USB-Stick geschrieben.
Auf diesem USB-Stick müssen nun im Verzeichnis „isolinux“ zwei Dateien bearbeitet werden: adtxt.cfg und isolinux.cfg.
Hier muss die Zeile mit vga=788 angepasst werden, bzw. der Eintrag für die serielle Konsole hinzugefügt werden.
Die Dateien müssen dann wie folgt aussehen.

adtxt.cfg:

label expert
	menu label E^xpert install
	kernel /install.amd/vmlinuz
	append priority=low vga=off console=ttyS0,115200n8 initrd=/install.amd/initrd.gz --- console=ttyS0,115200n8 
include rqtxt.cfg
label auto
	menu label ^Automated install
	kernel /install.amd/vmlinuz
	append auto=true priority=critical vga=788 initrd=/install.amd/initrd.gz --- quiet

isolinux.cfg:

# D-I config version 2.0
# search path for the c32 support libraries (libcom32, libutil etc.)
serial 0 115200
console 0
path  
include menu.cfg
default vesamenu.c32
prompt 0
timeout 0

Zeit für den ersten Boot.

Zuerst muss noch das serielle Kabel von der Firewall mit dem Rechner verbunden werden.
Hier dann ein Terminal-Programm öffnen und als Eingang die serielle Schnittstelle auswählen.

Zwar ist das BIOS mit einem Passwort versehen, aber die Firewall bootet vom USB-Stick.
Und siehe da, das Installer-Menü von Debian wird angezeigt.

Auf die Installation von Debian gehe ich nicht näher ein, dazu gibt es genügend Anleitungen im Internet.
Nur vielleicht soviel: ich verwende „Expert Install“ unter „Advanced Options“.
Beim Installations-Punkt „Load installer components from install media“ wähle ich „openssh-client-udeb“ aus, damit ich ab diesem Schritt dann die Installation über eine ssh-Verbindung weiterführen kann.
Man kann es aber auch komplett über die serielle Konsole machen.
Den Punkt „Select and install software“ überspringe ich, somit kann ich sicher sein nur das nötigste installiert zu haben.

Nach einem Reboot ist das Debian entweder weiterhin über die serielle Konsole erreichbar, oder kann über die vergebene IP-Adresse via ssh erreicht werden.
Da das System recht nackt ist, installiere ich erstmal ein paar Sachen nach, bevor ich dann Docker installieren kann.

sudo apt install bash-completion vim curl wget screen

Dann setze ich in „/etc/network/interfaces“ noch eine statische IP-Adresse für die erste Netzwerkkarte und die weiteren Netzwerkkarten werden ohne IP-Adresse konfiguriert.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug enp1s0
#iface enp1s0 inet dhcp
auto enp1s0
iface enp1s0 inet static
        address 192.168.123.33
        netmask 255.255.255.0
        gateway 192.168.123.1
        broadcast 192.168.123.255
        dns-nameserver 192.168.123.1

# This is an autoconfigured IPv6 interface
#iface enp1s0 inet6 auto#

# Unmanaged Interfaces
auto enp2s0
iface enp2s0 inet manual

auto enp3s0
iface enp3s0 inet manual

auto enp4s0
iface enp4s0 inet manual

Nächster Schritt: Docker
Zeit für die Docker-Installation.
Ich installiere Docker direkt von der Docker-Seite nach der dortigen Beschreibung

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

Und sollte mit etwa einer solchen Meldung enden

Server: Docker Engine - Community
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:56 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.13
  GitCommit:        9cc61520f4cd876b86e77edfeb88fbcd536d1f9d
 runc:
  Version:          1.0.3
  GitCommit:        v1.0.3-0-gf46b6ba
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

================================================================================

To run Docker as a non-privileged user, consider setting up the
Docker daemon in rootless mode for your user:

    dockerd-rootless-setuptool.sh install

Visit https://docs.docker.com/go/rootless/ to learn about rootless mode.


To run the Docker daemon as a fully privileged service, but granting non-root
users access, refer to https://docs.docker.com/go/daemon-access/

WARNING: Access to the remote API on a privileged Docker daemon is equivalent
         to root access on the host. Refer to the 'Docker daemon attack surface'
         documentation for details: https://docs.docker.com/go/attack-surface/

================================================================================

Docker-Compose installation
Danach installiere ich noch Docker-Compose

sudo apt install libffi-dev libssl-dev python3-dev python3 python3-pip
sudo pip3 install docker-compose

Als nächstes muss ich Docker noch als Dienst aktivieren ….

sudo systemctl enable docker

… und ich füge meinen aktuellen User der Gruppe „docker“ hinzu, damit ich nicht immer mit „sudo“ arbeiten muss.

sudo usermod -aG docker ${USER}

Und damit wäre das System bereit für die ersten Tests mit Docker.

Nachdem nun Docker und Docker-Compose installiert wurden, kann gleich mal getestet werden, ob alles funktioniert.
Dazu nutze ich PiHole und Portainer und ich nutze beides mit Docker-compose. Der Vorteil liegt darin, dass ich eine Datei „docker-compose“ habe und nicht einen langen Start-Befehl eingeben muss.
Allgemeines
Die Gretchenfrage ist nun, wo lege ich die Docker-Compose-Dateien ab. Grundsätzlich ist es dem Linux-system egal, wo man die Dateien ablegt, solange man pro Docker-Compose-Applikation einen eigenen Ordner hat. Grundsätzlich sollten auch alle User darauf zugreifen können, welche Docker auf einer Maschine verwalten.
Der FHS (Filesystem Hierarchy Standard) zu folge, wäre der Ordner „/srv“ wohl der richtige Ordner.
Man kann aber auch einen Ordner ausserhalb der Linux-Vorgaben anlegen.
Aber das soll für den kurzen Einstieg keine Rolle spielen, wehalb ich für diesen Eintrag erstmal in meinem Homeverzeichnis bleibe.

Ich starte einfach mit dem Container „PiHole“

PiHole
Das schöne an PiHole ist, dass man beim Herumspielen auch schon sofort ein Ergenbis hat.
Ich suche PiHole auf DockerHub. Im Suchfeld einfach „PiHole“ eingeben und schon bekommt man einige Treffer. Ich nehme das Image „pihole/pihole“.
Öffnet man den Suchtreffer, bekommt man eine Docker-Compose-Beipieldatei.
Bei Docker-Compose können in das docker-compose.yaml-File auch Variablen übergeben werden. Dafür gibt es die versteckte „.env“-Datei.

Zuerst lege ich im Homeverzeichnis „~“ ein Unterverzeichnis „docker“ and und darin ein Verzeichnis „pihole“
In dieses Verzeichnis „~/docker/pihole“ lege ich die 2 Dateien ab.
Hier die beiden Dateien:
Zuerst die das „docker-cpompose.yaml“.

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    hostname: ${HOSTNAME}
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
     #- "67:67/udp"
      - "445:443/tcp"
      - "85:80/tcp"
    environment:
      TZ: ${TZ}
      WEBPASSWORD: ${WEBPASSWORD}
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole/:/etc/pihole/'
      - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    # Recommended but not required (DHCP needs NET_ADMIN)
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    cap_add:
      - NET_ADMIN
    restart: unless-stopped

Wie man sieht, habe ich hier den Hostnamen, die Zeitzone und das Webpasswort für Variablen angepasst.
Diese übergebe ich mit der „.env“-Datein

TZ=Europe/Berlin
WEBPASSWORD=ChangeMe
HOSTNAME=PiholeDocker

Zeit den Container zu starten:

cd ~/docker/pihole
docker-compose up -d

ob der Container Läuft kann man mit „docker ps“ prüfen.

testuser@test01:~/docker/pihole$ docker ps
CONTAINER ID   IMAGE                  COMMAND      CREATED              STATUS                    PORTS                                                                                      NAMES
59dc3b25d741   pihole/pihole:latest   "/s6-init"   About a minute ago   Up 56 seconds (healthy)   0.0.0.0:53->53/tcp, 0.0.0.0:53->53/udp, 67/udp, 0.0.0.0:85->80/tcp, 0.0.0.0:445->443/tcp   pihole
testuser@test01:~/docker/pihole$

Im „docker-compose.yaml“-file habe ich angegeben, dass der Port 85 auf den Port 80 des containers weitergeleitet werden soll.
Somit kann ich PiHole nun mit „http://:85/admin“ aufrufen.

Und mich anmelden.

Im Homeverzeichnis habe ich unter „pihole“ nun zwei weitere Dateien: „etc-dnsmasq.d“ und „etc-pihole“.
Das sind Verzeichnisse, welche dem Docker-Container im lokalen Festplattenspeicher zugewiesen sind und wo persistente Daten von Pihole gespeichert werden.
Ab jetzt brauche ich nur das Verzeichnis „pihole“ komplett zu sichern und kann es an jedem beliebigen Rechner (mit installiertem Docker-Compose) wieder ohne Datenverlust starten.

Portainer
Ich möchte auch noch kurz den Portainer installieren. Leider gibt es auf der Community-Seite nur einen Befehl zum starten. Ich würde aber gerne Docker-Compose verwenden.
Auf der Portainer-Community-Seite wird unter „Deployment“ ein Docker-Volume erzeugt, welches ich so ebenfalls nicht nutzen möchte. Ich hätte gerne wieder eine lokale Ablage.
Zuerst lege ich wieder das Verzeichnis an „~/docker/portainer“ und erzeuge darin eine „docker-compose-yaml“-Datei mit folgendem Inhalt:

version: '3.3'
services:
    portainer-ce:
        image: 'portainer/portainer-ce:2.9.3'
        container_name: portainer
        restart: always
        ports:
            - '8000:8000'
            - '9000:9000'
                volumes:
            - '/var/run/docker.sock:/var/run/docker.sock'
            - './portainer_data:/data'

Wenn ich jetzt in das Verzeichnis „~/docker/portainer“ wechsel und den Container starte

docker-compose.yaml up -d

Wird das Image heruntergeladen und der Container gestartet.

Mit „docker ps“ kann ich wieder controllieren, ob der Container gestartet ist:

testuser@test01:~/docker/portainer$ docker ps
CONTAINER ID   IMAGE                          COMMAND        CREATED          STATUS                    PORTS                                                                                      NAMES
81fdb4baea55   portainer/portainer-ce:2.9.3   "/portainer"   42 seconds ago   Up 38 seconds             0.0.0.0:8000->8000/tcp, 0.0.0.0:9000->9000/tcp, 9443/tcp                                   portainer
59dc3b25d741   pihole/pihole:latest           "/s6-init"     22 minutes ago   Up 22 minutes (healthy)   0.0.0.0:53->53/tcp, 0.0.0.0:53->53/udp, 67/udp, 0.0.0.0:85->80/tcp, 0.0.0.0:445->443/tcp   pihole
testuser@test01:~/docker/portainer$

Und man kann nun in einem Browser mit „http://:9000“ den Portainer aufrufen.
Bei der Erstanmeldung muss man noch ein Passwort vergeben

Danach kann man auch hier seine Docker-Container verwalten.

Nun kann das Spielen mit Docker beginnen ….

Für ein privates (länger laufendes) Projekt benötige ich einen sparsamen Rechner.
RaspberryPi ist da ja meist die erste Anlaufstelle – also in meiner Elektronikkiste gekramt und das eine oder andere Teil gefunden.
Neben einen RPI3, der aber für ein anderes -ruhendes- Projekt aufgebaut war, war noch ein Raspberry1B und ein BananaPI vorhanden.
Erstaunlicherweise hat der BananaPI einen geringeren Stromverbrauch als der Raspberry1.
So ist die Enscheidung auf den BananaPI gefallen ….. und der Start war etwas holprig.

Mein erster Anlauf war natürlich die eigentliche Adresse allnet.de. Aber die Links gingen leider in’s Leere.
Aber es gab ja noch die Seite www.lemaker.org. Auf dieser Seite fanden sich allerlei Betriebssysteme, aber die Angaben der Erscheinungsjahre waren alle andere als vertrauenserweckend (2014/2015).
Einzig das Archlinux als „Rolling Release“ erschien mir als brauchbare Alternative – in der Hoffnung, es würde sich nach 7 Jahren immer noch als „Rolling Release“ updaten lassen.
Aber die Frage bleibt wohl unbeantwortet, denn der Download-Link verwies auf ein GoogleDrive, das erstmal eine Anmeldung wollte. Nach der Anmeldung wurde mir mitgeteilt, dass das File nicht mehr verfügbar war.
Danke.
Aber es gibt ja noch die Seite banana-pi.org.
Doch hier wurde mein altes Board nicht mehr aufgelistet, es wurde aber auf das forum.banana-pi.org verwiesen.
Dort gibt es einen Button „Downloads“, der aber wiederum auf Banana-pi.org verweist und einen 404-Fehler bringt.
Im Forum selber fanden sich einige Anleitungen, deren Links, aber ebenfalls in’s Leere liefen.
Bei einer Suche im Debian-Forum wurde ich dann fündig. Eine Anleitung (Debianforum.de) inkl. funktionierenden Downloadlink (ftp.uk.debiab.org).
Aber was soll ich sagen … hat nicht funktioniert.

Leicht gefrustet bin ich dann auf das armbian aufmerksam geworden. Hier gab es direkt einen Link für meinen BananaPI und das auch noch recht aktuell (Jammy auf Ubuntu-Basis und bullseye auf Debian-Basis). Meine Wahl viel auf „bullseye“ (Armbian_22.05.4 Kernel 5.15.48).
Des Weiteren musste ich noch USBImager herunterladen um das gezippte Image direkt auf eine SDKarte schreiben zu können und mir so den Umweg über das vorherige Entpacken zu sparen.

Die Installation selber verlief dann, wie von anderen „Images_to_USB/SD“-Programmen gewohnt, sehr einfach.
Das Image belegt ca 1,4GB und wird beim ersten Start auf die Größe der SD-Karte erweitert.

Also erster Test: SD-Karte rein und BananaPi an.

Beim ersten Start verlangt armbian ein root-Passwort.
Man kann zu diesem Zeitpunkt aber auch schon eine SSH-Verbindung zum System aufbauen und sich mit
User: Root PWD: 1234
anmelden.
Nach der Anmeldung wird man, wie auf der Konsole selber, erstmal nach einen neuen root-Passwort gefragt. Hier ist die Passwort-Komplexität aktiviert und es funktionieren keine simplen Passwörter.

Welcome to ARMBIAN!

Documentation: https://docs.armbian.com | Community: https://forum.armbian.com

Create root password: ***********

Dann wird man gefragt, ob man bash oder zsh verwenden möchte.
Ich bleibe, ganz klassisch, bei der bash

Choose default system command shell:

1) bash
2) zsh

Shell: BASH

Es folgt die Frage nach einem Benutzerkonto
(Achtung auch hier wird eine gewisse Passwortkomplexität erwartet).

Creating a new user account. Press  to abort

Please provide a username (eg. your first name): pi
Create user (pi) password: ***********
Repeat user (pi) password: ***********

Please provide your real name: Pi

Dear Pi, your account pi has been created and is sudo enabled.
Please use this account for your daily work from now on.

Und zum Abschluss kommt noch die Frage nach dem Standort

Detected timezone: Europe/Berlin

Set user language based on your location? [Y/n]

At your location, more locales are possible:

1) de_DE.UTF-8
2) hsb_DE.UTF-8
3) Skip generating locales
Please enter your choice:1

Generating locales: de_DE.UTF-8
root@bananapi:~#

Damit läuft der BananaPI schonmal.
Möchte man andere Passwörter für „root“ und den User „PI“ vergeben, kann man das jetzt einfach mit passwd erledigen

passwd pi
passwd root

Als nächstes möchte ich das Anmelden von root am System verhindern

sudo nano /etc/passwd

#Zeile von /bin/bash für root abändern
root:x:0:0:root:/root:/usr/bin/false

Und auch das Anmelden von Root über ssh unterbinde ich.

sudo nano /etc/ssh/sshd_config

#Zeile mit
PermitRootLogin yes
#auf
PermitRootLogin no
#ändern

zum Abschluß noch ein Reboot

sudo reboot

Und damit ist der BananaPI bereit für seinen zukünftigen Einsatz.

Zumindest fast ……

Nachdem der BananaPI nun endlich läuft, war er bereit für seinen Einsatz: Loggen von Daten über einen längeren Zeitraum.
Jedoch hatte ich mit dem RaspberryPI schonmal schlechte Erfahrungen mit der Haltbarkeit von SSD-Karten gemacht, die viele Zugriffe hatten. Zum Glück hat der BananaPi einen SSD-Anschuß

Aber auch hier stolperte ich erstmal über das Problem der nicht funktionierenden Anleitungen und toten Links.
Nach einer längeren Suche stolperte ich dann auf einen Link, der in einem Forum (https://bananapi.gitbook.io) sehr vielversprechend aussah, weshalb ich den weiterführenden Link, der mittlerweile in’s Nichts verwies, dann über das web.archive.org gesucht und gefunden habe.

Hier also die Schritte zusammengefasst.

Die SSD mit dem dazugehörigen Kabel anstecken und den BananaPI neu starten.
Zuerst teste ich mit fdisk -l, ob die SSD gefunden wurde.
Danach habe ich mit cfdisk auf der SSD eine primäre Partition erstellt (ist bequemer als mit fdisk) und diese als Typ Linux gekennzeichnet.
Um sich einen Neustart zu sparen kann man die Partitionstabelle mit sudo partprobe /dev/sda neu einlesen.
Der nächste Schritt ist das Formatieren der neu erstellten Partition

sudo mkfs.ext4 /dev/sda1

Somit ist alles vorbereitet um das Betriebssystem auf die SSD zu übertragen

Zuerst mounte ich die Partition in das Verzeichnis /mnt

sudo mount /dev/sda1 /mnt

Danach kann man das komplette root-Filesystem kopieren

sudo rsync -axv / /mnt

Jetzt müssen wir noch die SSD als root-Partition bekannt machen.
Dazu lese ich zuerst die BlockID der Partition aus

sudo blkid /dev/sda1
/dev/sda1: UUID="8a948549-a40d-40b0-b3da-d4e411e995df" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6cc7ab35-01"

Dann trage ich die Partition in der fstab ein und hashe gleichzeitig die SD-Karte aus.

sudo nano /etc/fstab
#UUID=d1799676-40cb-4b00-852a-f233e26ba32b / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1
UUID=8a948549-a40d-40b0-b3da-d4e411e995df / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1
tmpfs /tmp tmpfs defaults,nosuid 0 0

Und natürlich muss auch der Bootloader angepasst werden

sudo nano /boot/armbianEnv.txt
...
#rootdev=UUID=d1799676-40cb-4b00-852a-f233e26ba32b
rootdev=UUID=8a948549-a40d-40b0-b3da-d4e411e995df
...

Da die Daten im Livesystem geändert wurden, lasse ich den rsync-Befehl von oben noch einmal laufen

sudo rsync -axv / /mnt

Jetzt noch sauber die SSD aushängen ….

sudo umount /mnt

… und das System neu starten

sudo reboot

Nach dem Neustart kann man mit df -Th prüfen, ob die SSD richtig eingebunden wurde

df -Th
Dateisystem    Typ      Größe Benutzt Verf. Verw% Eingehängt auf
udev           devtmpfs  431M       0  431M    0% /dev
tmpfs          tmpfs      97M    3,2M   94M    4% /run
/dev/sda1      ext4       30G    1,2G   27G    5% /
tmpfs          tmpfs     484M       0  484M    0% /dev/shm
tmpfs          tmpfs     5,0M    4,0K  5,0M    1% /run/lock
tmpfs          tmpfs     484M       0  484M    0% /tmp
/dev/zram1     ext4       49M    288K   45M    1% /var/log
tmpfs          tmpfs      97M       0   97M    0% /run/user/1000

Wenn man möchte kann man jetzt noch die ehemalige root-Partition auf der SD-Karte löschen

Nachdem der Bananapi nun auch von der SSD läuft, kann ich nun endlich seine eigentliche Funktion einrichten: das Auslesen von mehreren Temperaturen per 1wire.
Auch hier habe ich wieder etliche Anleitungen gefunden und musste verschiedenste Anleitungen absatzweise kombinieren, denn die meisten waren schlichtweg zu alt.

Das Tolle am armbian ist, dass das armbain-config mitgeliefert wird, was dem raspi-config am Raspian entspricht.
Damit lässt sich das 1wire-GPIO sehr einfach aktivieren und man spart sich den händischen Weg.

sudo armbian-config

Navigieren zu :
Navigate -> System -> Hardware -> Select w1-gpio -> Save -> Back -> Reboot.

Nach dem Reboot lässt sich über dmesg prüfen, ob die Aktivierung geklappt hat

dmesg | grep wire
[    9.075562] Driver for 1-wire Dallas network protocol.
[    9.116162] gpio-271 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file
[   60.627835] w1_master_driver w1_bus_master1: Attaching one wire slave 00.800000000000 crc 8c

Soweit gut, aber man muss noch den Pin angeben, der für 1wire genutzt werden soll.
Die Pins am Bananapi:

Ich wähle PI3 (gleichzusetzen mit PI03) welcher am Pin7 anliegt.

Jetzt editiere ich die Datei /boot/armbianEnv.txt und füge folgende Zeile hinzu.

param_w1_pin=PI3

Danach muss der BananaPI neu gestartet werden

sudo reboot

Jetzt kommt die Verkabelung.
Es muss Pin1 (3,3V), Pin7 (PI3=Data) und Pin9 (GND) angeschlossen werden. Zwischen Pin1 und Pin7 muss ein 4,7kOhm Widerstand angeschlossen werden.

echo "scale=2; $(cat temperature) /1000" | bc