FHEM Watchdog mit Systemd

Details

Geschrieben von Alexander Schulz

Kategorie: FHEM

Veröffentlicht: 04. März 2018

Zugriffe: 40819

• FHEM
• Watchdog
• Überwachung

Ich habe jetzt endlich Zeit genommen, meine alte Bastelei (http://s6z.de/cms/index.php/homeautomation-homecontrol/softwareplattformen/fhem/23-fhem-watchdog) über Bord zu werfen. Moderne Linux-Systeme verwendet systemd, der kann das besser out-of-the-box.

Nachdem ich im Forum eine gute Vorlage (https://forum.fhem.de/index.php/topic,85231.msg775822.html#msg775822) gefunden habe, erstelte ich kurzerhand daraus ein leicht zu verwendendes Modul. Zu finde ist wie immer im GitHub: https://raw.githubusercontent.com/hexenmeister/MyFHEM/master/FHEM/98_systemd_watchdog.pm Wenn sich das gute Stück bewehrt, checke ich es auch ins FHEM-SVN-Repo ein.

Hier ist ein Kurzanleitung für die Instalation:

• Sicherstellen, dass das eigene System unter Kontrolle von Systemd läuft. Dürfte bei den meisten aktuellen Linux-Distributionen der Fall sein.
• Datei 98_systemd_watchdog.pm in das FHEM-Modulverzeichnis kopieren. Link: https://raw.githubusercontent.com/hexenmeister/MyFHEM/master/FHEM/98_systemd_watchdog.pm
• In FHEM Watchdog-Device erstellen:
  define watchdog systemd_watchdog
• Bleibt es bei Type=forking, dann sicherstellen, dass FHEM eine PID-Datei schreibt. Ggf. global Attribute pidfilename seiten:
  attr global pidfilename /var/run/fhem/fhem.pid
  Bei Type=notify muss nofork=1 gesetzt werden:
  attr global nofork 1
• FHEM beenden, falls noch läuft.
• Sicherstellen, dass FHEM mittels systemd-script gestartet wird. Ggf. noch vorhandenen init.d-Script entfernen.
• Systemd-Script (Inhalt s.u.) erstellen:
  sudo nano /opt/fhem/config/fhem.service
  
• Script aktivieren:
  sudo systemctl enable /opt/fhem/config/fhem.service
• Systemd-Konfiguration aktualisieren:
  sudo systemctl daemon-reload
• FHEM starten:
  sudo systemctl start fhem.service
• Prüfen, ob alles wie gewünscht funktioniert: FHEM wird nicht alle 3 Minuten durch den Watchdog gekillt, beim Beenden mittels kill -9 wird neu gestartet, bei shutdown (aus FHEM) jedoch nicht. <- shutdown klappt doch nicht :/

 Hier ist das Startscript (fhem.service):

[Unit]
Description=FHEM Home Automation
Requires=network.target
#After=network.target
After=dhcpcd.service

[Service]
Type=forking
NotifyAccess=all
User=fhem
Group=dialout
# Run ExecStartPre with root-permissions
PermissionsStartOnly=true
ExecStartPre=-/bin/mkdir -p /var/run/fhem
ExecStartPre=/bin/chown -R fhem:dialout /var/run/fhem
# Run ExecStart with defined user and group
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
TimeoutStartSec=240
TimeoutStopSec=120
#ExecStop=/usr/bin/pkill -U fhem perl
ExecStop=/usr/bin/pkill -f -U fhem "fhem.pl fhem.cfg"
# Restart options: no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always.
Restart=on-failure
RestartSec=3
WatchdogSec=180
PIDFile=/var/run/fhem/fhem.pid

[Install]
WantedBy=multi-user.target

 

Das Modul erzeugt zwei Readings:
state: gibt an, ob die Instanz aktiv ist (ist automatish der Fall, wenn Systemd-Watchdog verfügbar ist)
next: zeigt den Zeitpunkt der nächten keep-alive-Meldung

Außerdem gibt es zusützlich zu den allgemeinen 'Internals' zwei weitere:
sleep-time: Zeitinterval zw. den keep-alive-Meldungen (wird aus dem im Watchdog definierten Interval ausgerechnet, es wird ein Vietel von der maximalen Zeit verwendet).
systemd-watchdog: zeigt an, ob Systemd-Watchdog verfügbar ist.

Update: Mit Hilfe von ExecStartPre wird jetzt das Verzeichnis für die PID-Datei bei Bedarf erstellt und der fhem-User als Besitzer eingetragen.

Update2: Nach einer Testphase habe ich das Modul in das offizielle Repo eingecheckt und im Forum beschriben: https://forum.fhem.de/index.php/topic,90438.0.html

Platinenhersteller: ALLPCB

Details

Geschrieben von Alexander Schulz

Kategorie: Sonstiges

Veröffentlicht: 02. Januar 2018

Zugriffe: 39045

• PCB Design

Neulich bin ich auf ein Angebot eines Platinenherstellers aus China aufmerksam geworden: ALLPCB. Für 10 Stück 2-layer Platinen in der Größe vom bis 100x100mm sollten lediglich 5$ incl. Versand fällig werden. Das war schon eigentlich zu gut, um wahr zu sein. Das musste ich ausprobieren. :)

Nach der Abwicklung wurde ich gefragt, ob ich meine Erfahrung teilen möchte... Warum denn auch nicht? Youtube-Videos sind zwar nicht mein Ding, aber wozu hat man ein Blog?

Zum Testen habe ich eine fertige Platine in der Größe 50x50mm ausgesucht und zusätzlich eine kleine Adapterplatine (die ich eh haben wollte) entworfen.

 

 Jetzt nur noch daraus Gerbers exportieren und die Bestellung aufgeben.

Die Adresse lautet: http://www.allpcb.com/online_quote.html. Bestelltformular bietet die üblichen Optionen, der günstige Preis gilt nur für eine bestimmte Konfiguration, die jedoch in den allermeisten Fällen geeignet ist. Also werden die Platinen eben grün, 1,6mm dick etc.

Den Versand mit TNT oder DHL inklusive hatte ich bei dem Preis definitiv nicht erwartet, aber die Bestellung ging nach dem Hochladen von Gerbers und Bezahlung per PayPal erstmal so weg. Es war (in Deutschland) Sonntag und schon so gegen Mitternacht.

Die erste Rückmeldung bekam ich wenige Stunden später im Zug, auf dem Arbeitsweg. Ich wurde darauf hingewiesen, dass einige Beschriftungen etwas zu klein sind und schlecht zu lesen sein werden.

Diese waren mir nicht weiter wichtig und so habe ich zurückgefragt, ob das doch so in die Maschine kann. Keine 10 Minuten später las ich die Antwort, es hieß sinngemäß, meine Platinen wären jetzt drin :) Hm... Schnell die Jungs!

Expressversand war kein leeres Versprechen, am Donnerstag hielt ich meine Bestellung in den Händen.

Eingeschweißt und sehr ordentlich verpackt.

Die Platinen selbst sind völlig in Ordnung, so, wie ich das auch von anderen chinesischen Platinenhersteller kenne. Es waren sogar paar mehr dabei (11 und 14), was jedoch auch nicht unüblich ist.

 

 Inzwischen hatte ich eine größere Platine (100x60mm) in Auftrag gegeben, auch diese kamen wieder innerhalb einer Woche bei mir an.

 Diesmal war die Zustellung etwas weniger zärtlich, der Karten kam verbeult an.

 Dank der guten Verpackung waren die Platinen jdoch unversehrt geblieben.

 

Es wurden wieder mehr Platinen (11 Stück) geliefert, die Qualität scheint tadellos zu sein (ich muss sie noch aufbauen und testen).

Die Qualität und die Geschwindigkeit entspachen der ersten Bestellung.

Zusammenfassend kann ich diesen Fertiger weiter empfehlen. Ich vermute jedoch, der Preis wird auf Dauer so nicht bleieben, hier geht es bestimmt um eine Gewinnung neuer Kunden. Ich behalte das mal im Auge :)

---

Update:

Natürlich war das eine Promotion-Aktion und der Preis hat sich mittlerweile normalisiert. Dennoch sind z.B. 15 Euro für 5 Stück 100x100mm 2-layer PCBs incl. free Versand mit TNT/DHL (ca 5-7 Tage) oder 21 Euro für 30 Stück 50x50mm mehr als in Ordnung. Alleine schon wegen dem schnellen Versand :)

---

Update 04.01.2018:

Habe heute noch eine selbstdesignte Platine in Autrag gegeben und mich ein wenig über die Preisgestalltung gewundert. 10 Stück Platinen in der Größe von 25x75mm sollten 20 Dollarkosten, 30 Stück jedoch nur 19$. Alles inklusive Versand :O Habe dann letztendlich 50 Stück für 23,- bestellt. Der Preis pro Platine ist sehr gut und bei der Summe bekommt man auch kein Ärger mit dem Zoll.

Als Zahlung werden übrigend PayPal, Banküberweisung und 'eBay' akzeptiert. Banküberweisung mit der 30$ Gebühr ist wohl ziemlich uninteressant, 1,12$ für PayPal sind aber in Ordnung. Wie das mit dem 'eBay' funktioniert habe ich nicht rausgefunden, ist aber auch egal :D

 

---

WLAN-nRF-Bridge auf ESP8266-Basis

Details

Geschrieben von Alexander Schulz

Kategorie: ESP8266 - WIFI-Controler

Veröffentlicht: 21. April 2017

Zugriffe: 39810

• ESP8266
• PCB Design

Endlich habe ich wieder Zeit gefunden (genommen), mein eigentlich schon etwas älteres Projekt vorzustellen. Diesmal handelt es sich um eine 2,4GHz-Funk-Bridge basierend auf nRF24L01+, einem Chip von Nordic Semiconductor, die per WLAN gesteuert werden kann. Wer sich dafür interessiert, was dieser Funk-Tranceiver-Chip alles kann, wird auf der Seite des Herstellers fündig: http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P. Eine gute Beschreibung liefert (wie immer) auch mikrocontroller.net: https://www.mikrocontroller.net/articles/NRF24L01_Tutorial

Für alle anderen sei gesagt, dass dieser Chip für die Kommunikation der Geräte verwendet wird, die auf der MySensors-Bibliothek basierend aufgebaut sind. Es sind natürlich auch andere Verwendungen möglich, z.B. gibt es Implementierungen, die es erlauben, MiLight-Lampen zu steuern (mehr dazu hier: https://forum.fhem.de/index.php/topic,58742.0.html,58742.0.html).

 

Mein primäres Ziel war ein MySensors-Gateway für mein Automationserver aufzubauen. Der Schaltplan basiert auf dem Vorschlag auf der MySensorsSeite (https://www.mysensors.org/build/connect_radio#nrf24l01+-&-esp8266) und ergänzt diesen praktisch nur um die Spannungsversorgung. 

Die grundsätzlichen Eigenschaften der Platine sind folgende:

• Spannungsversorgung über MicroUSB-Buchse (5V) oder über Schraubklemmen (7-12V, mit Verdunstungsschutz), geschützt durch eine selbstrückstellende Sicherung.
• Verwendung von günstigen und gut verfügbaren Komponenten (ESP12 und nRF24L01+)
• Verwendung nRF24L01+ als SMD- oder steckbare Version
• Anschluss für den UART-Adapter zum Debuggen/Flashen, Reset- und Flash-Buttons
• 3 LEDs und ein Button (Inclusion) für MySensors-Gateway-Sketch
• Vorbereitung für optionalen CryptoAuthentication-Chip (ATSHA204A)

An dieser Stelle noch mal ein großes Dankeschön an alle, die sich bei der Diskussionen im Forum beteiligt haben: https://forum.fhem.de/index.php/topic,46304.0.html, sowie für alle Ratschläge, Tests und Korrekturen!

 

Schaltplan und Board sind in Eagle-CAD designt worden und auf GitHub hinterlegt: https://github.com/hexenmeister/PCB-Design/tree/master/ESP8266_MySensorsGateway

 

Seit der ersten Version haben Schema und Layout mehrere Korrekturen erfahren und es sind auch mehrere Chargen gefertigt worden.

 

Renders für die aktuelle Board-Version:

 

Verschiedene Versionen und Fertigungschargen:

 

Fertig aufgebaute Platinen:

 

---

 Anleitung zum Aufbau und Test der Platine:

 Aufbau:

 Den Aufbau der Platine schlage ich in folgender Reihenfolge vor:

• USB-Buchse
  (Mit den winzigen Buchsen musste ich vorerst ein wenig üben, aber nach ein paar Versuchen (ruhige Hand vorausgesetzt) ging es ganz gut. Die letzte Board-Version verwendet Buchsen mit durchsteckbaren Lötfähnchen, diese sind viel leichter zu handhaben.
  Die Vorgehensweise: auf die Lötflächen etwas Flussmittel (bitte kein Kolophonium oder so was in der Art) auftragen, dann mit etwas (wenig!) Lötzinn die Flächen bearbeiten, ggf. auf die Kontaktflächen wieder etwas Flussmittel (übertriebene Sparsamkeit ist hier fehl am Platz ;D ). Dann die Buchse genau platzieren und die Kontakte leicht anlöten. Wenn alles genau und sauber sitzt, das Gehäuse an den Lötlaschen an die PCB festlöten (kann ruhig viel Lot sein)). Jetzt die Kontakte einzeln und praktisch ohne Lot (was zuerst auf die Kontaktflächen schon aufgetragen war, reicht). Viel Flussmittel verhindert unerwünschte Brücken. Mit viel Licht und einer Lupe überprüfen! Am Besten auch elektrisch kontrollieren - also anschießen und messen. Bei manch einer Platine hatte ich schon einen Wackelkontakt, beim Wackeln am Stecker stürzte ESP ab - es musste nachgelötet werden. Endkontrolle ist also unerlässlich!
  
  
• Widerstände (R1-R2, R4-R14: 13x 10k und R15: 1x 470 (oder 680,oder 1k…), den R3 lässt man am besten weg, dieser ist für die WakeUp-Schaltung, sie macht bei einem Gateway wenig Sinn.
  
  
• SMD Kondensatoren (C1, C4, C5: 3x 100n (104) und C3: 1x 1µF (105))
  
  
• wenn nRF in einer SMD Version verwendet wird, dann kann jetzt dieser angelötet werden (ich klebe ein Stückchen Kaptonband darunter, es sollte zwar auch ohne keine Kurzschlüsse geben, aber sicher ist sicher)
  
  
• Stromregler
  
  
• PolyFuse
  
  
• LEDs (abgeschrägte Ecken zeigen Richtung Platinenmitte)
  
  
• ggf. Diode (falls Versorgung über die Schraubklemmen verwendet werden soll. Polarität beachten! Markierung zeigt Richtung LEDs)
  
  
• Taster
  
  
• ESP12
  
  
• C2: bei älteren Versionen - ELKO (auf die Polarität achten!) (ist etwas blöde gelöst, damit die Platine möglichst flach wird, muss dieser mit angewinkelten Beinchen liegend bestückt werden. Und zwar von der anderen Platinenseite, als angezeichnet!)
  bei neueren Versionen wird eine MLCC 107 verwendet
  
  
• PRG-Leiste (es hat sich herausgestellt, dass diese besser an der anderen Platinenseite platziert werden soll, als angezeichnet!)
  
  
• falls steckbarer nRF verwendet wird, ist der jetzt dran. Entweder gesteckt auf einer 2x8 female PinHeader oder direkt angelötet (damit wird die Platine wesentlich flacher).
  
  
• vor allem bei Verwendung von nRF-Modulen mit Verstärker (PA+LNA) hat es sich bewährt, zusätzlich direkt zwischen den VCC und GND Anschlüssen des nRF-Moduls einen zusätzlichen Kondensator (105) anzulöten.

 Das wär's dann auch schon! 

 

Teileliste:

• (1x) 00. PCB
• (1x) 01. µC: ESP-7/ESP-12/ESP-12e/ESP-12f
• (1x) 02. IC1: AMS1117 3.3
• (1x) 03. Radio: nRF24L01+ (SMD oder THT)
• (10x) 04. R1,R2,R4-R11 : 10K (12K tut auch)
• (3x) 05. R12-R14: 10k (bzw. je nach LED)
• (2x) 06. R3,R15: 470 (oder 680, oder 1k...)
• (3x) 07. C1,C4,C5: 100n
• (1x) 08. C2: 10uF (unkritisch, größer besser, z.B. 100uF)
• (1x) 09. C3: 1uF
• (1x) 10. D1: Schottky Diode SS14 (oder andere)
• (1x) 11. PF1: 500mA max
• (3x) 12. Taster: 3x SMD 6x2,5mm
• (1x) 13. MicroUSB-Buchse
• (1x) 14. Screw Terminal 2 pins: 5,08 mm pitch (W237-02P)
• (1x) 15. PinHeader male 4 pins: 2,54 mm pitch
• (1x) 16. PinHeader female 2x4 pins: 2,54 mm pitch (optional, nRF-Modul kann auch direkt angelötet werden)
• (3x) 17. LED1-LED3 (r,g,y)

Verwendeten SMD-Packages:

• R1-R15: 0805
• C1,C3-C5: 0805
• C2: 1210
• LEDs: 1206 / 1210
• PF1: 1206
• Taster: DTSM-3
• IC1: SOT223
• D1: DO214

---

 Test:

Nach dem Aufbau kann die Platine an die Stromversorgung (per USB oder Schraubklemme, ggf. auch über PRG-Leiste, aber nur, wenn dort genügend Strom geliefert wird (was bei vielen USB-UART-Adaptern nicht der Fall ist). Das ESP-Modul soll sich dabei mit einem kurzen Blinken seiner blauen LED melden.

Über ein USB-UART-Adapter wird die Platine an ein USB-Port eines PCs angeschlossen (bei der Versorgung über USB/Klemmen sind nur Leitungen GND, RX und TX anzuschließen. RX und TX müssen natürlich über Kreuz an den Adapter angeschlossen werden).

 

Zum Flashen wird ArduinoIDE benötigt.

 

Also der Reihe nach:

• Arduino IDE installieren
• ESP-Erweiterung installieren (file -> preferences -> additional board manager urls für ESP8266 - http://arduino.esp8266.com/stable/package_esp8266com_index.json bei mehreren - mit Komma trennen)
• MySensors Bibliotheken von mysensors.org installieren
• Platine per USB-Uart-Adapter an den PC anschließen.
• in IDE den richtigen COM-Port auswählen
• Platine an ein Netzteil anschließen
• in IDE folgendes auswählen: Platine: Generic ESP8266-Module, Flash-Size: 4M (1M SPIFFS), Flash-Mode: DIO
• FLASH-Taste drücken und halten, dann kurz RES drücken, FLASH loslassen.
• Sketch laden
  (mein Sketch für MySensors-Version 1.5.x: https://github.com/hexenmeister/MySensors_MyDevices/tree/master/MyEsp8266Gateway, für Version 2.x: https://github.com/hexenmeister/MySensors2x/tree/master/GatewayESP8266)
• WLAN-Passwort einstellen (bei meinen Sketches muss Datei MySecret.h entsprechend angelegt werden, Beispiel in GitHub)
• Kompilieren und flaschen (die Baudrate sollte 115200 Baud sein) 

Wenn man jetzt die serielle Console in IDE öffnet, sollten entsprechende Meldungen sichtbar sein. Die Platine meldet ggf. auch Fehler (radio init failed) und startet dann in einer Endlosschleife neu. In diesem Fall sollte die Bestückung überprüft werden.

Falls alles in Ordnung ist, kann man sich mit dem Gateway per Telnet (z.B. mit PuTTY) verbinden. IP-Adresse wird per DHCP bezogen (im Router-Config nachsehen), Port: 5003

Damit ist es eigentlich sicher, dass die Platine funktioniert. Wer ganz genau wissen will, benötigt jetzt ein MySensor-Device, das auf den gleichen Kanal konfiguriert ist. Die Messages von diesem Device werden sowohl in der seriellen Console, als auch über Telnet-Verbindung ausgegeben. Über Telnet können auch Befehle gesendet werden (Beispielweise: 101;1;1;1;0;TEST).

 

Live-Image der SD-Karte auf externem Medium erstellen und Mounten

Details

Geschrieben von Marco Pfannenstiel

Kategorie: Sonstiges

Veröffentlicht: 27. September 2015

Zugriffe: 28034

Live-Image der SD-Karte auf externem Medium erstellen und Mounten

 

Wer kennt es nicht, mal eben schnell einen Linuxbefehl getippt und schon ist etwas verbogen.
Jetzt wäre eine Sicherung nicht schlecht.....

Mit wenigen Handgriffen ermöglicht Linux das Erstellen einer Image-Datei auf einer angeschlossener Festplatte oder auf einer Netzwerkfreigabe.
Beim Crash der Karte kann man so eine neue mit dem Inhalt vom Vortag erstellen.

Aber was wenn man nur mal eine versehendlich gelöschte Datei zurück haben möchte?
Hier wäre die komplette Rücksicherung ein wenig zu viel des Guten.
Auch hier bietet Linux eine Möglichkeit das gesicherte Image in das laufende System zu mounten.

Eine mögliche Variante könnte jetzt das automatische Sichern des SD-Karten-Images an jedem Wochentag sein.
So stehen immer die letzten 7 Tage zu Verfügung.

 

---

 

Vorbereiten der Verzeichnisstruktur

 

Speicherort für die tägliche Sicherung anlegen, in diesem Fall ist es eine CIFS-Freigabe auf einem NAS-Server.

 

mkdir /mnt/NetBackup

 

Speicherort für den Imagemountpunkt anlegen, hier ist später das gemountete Image zu finden.

 

mkdir /mnt/NetBackup/ImageMount

 

---

 

Skript für die Erstellung des Live-Image anlegen

 

Für das automatische erstellen des Images wird ein kleines Skript genutzt.
Das Skript erstellt je nach Wochentag ein Image.

 

Vorher muss aber noch der Devicename der SD-Karte nachgesehen werden.

 

fdisk -l

Disk /dev/mmcblk0: 15.7 GB, 15720251392 bytes
4 heads, 16 sectors/track, 479744 cylinders, total 30703616 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
Disk identifier: 0x0009bf4f

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880    30703615    15290368   83  Linux

 

Jetzt eine neue Datei anlegen und den Inhalt hinein kopieren.

 

nano /bin/scripts/backup.sh

#!/bin/bash
# /bin/scripts/backup.sh

Weekday=$(date +%A)
EventDate=$(date +%e.%m.%Y-%T) 
BackUpFile="/mnt/NetBackup/$Weekday.img"

echo "$EventDate | start backup: $BackUpFile" 2>&1 >> /tmp/cron.log
#/dev/mmcblk0 ist in diesem Fall die SD-Karte, das kann aber variieren!
dd if=/dev/mmcblk0 of=$BackUpFile bs=1M 2>&1 >> /tmp/cron.log
echo "$EventDate | backup done" 2>&1 >> /tmp/cron.log

 

Skript ausführbar machen:

 

chmod +x /bin/scripts/backup.sh

 

---

 

Backup-Skript in die Crontab einbinden

 

Das Backup soll jede Nacht um 4.00h automatisch gestartet werden.
Hierzu wird das Skript in die user-crontab eingebunden.

 

crontab -e

0 4   * * *   /bin/scripts/backup.sh

 

Der user-crontab wird automatisch unter /var/spool/cron/crontabs abgelegt

 

 

Zusätzlich legt das Skript einen LOG-Eintrag im /tmp/cron.log an.

 

4.10.2015-13:04:01 | start backup: /mnt/NetBackup/Sunday.img
4.10.2015-13:04:01 | backup done

 

Jetzt wird jede Nacht um 4.00h im Ordner /mnt/NetBackup ein Image der SD-Karte abgelegt.

 

Optional kann der Crondienst neu gestartet werden und das LOG angezeigt werden.

 

service cron restart

grep CRON /var/log/syslog

 

---

 

Mounten des gesicherten Images

 

Das gemountete Image kann jetzt in das bestehende Dateisystem der SD-Karte gemountet werden.

Der erste Versuch schlug jedoch fehl. Ein superblock error. Klar, das Image enthält ja nicht nur die gewünschte Partition, sondern den gesamten Karteninhalt.

 

Aber das schöne an Linux ist ja gerade, dass man es trotzdem bewerkstelligen kann. Ein kurzer Besuch beim Onkel Google verrät auch wie es geht.

Zuerst werfen wir das Image dem fdisk vor die Füße:

 

fdisk -lu /mnt/NetBackup/Wednesday.img

Disk /mnt/NetBackup/Wednesday.img: 15.7 GB, 15720251392 bytes
255 heads, 63 sectors/track, 1911 cylinders, total 30703616 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
Disk identifier: 0x0009bf4f

                       Device Boot      Start         End      Blocks   Id  System
/mnt/NetBackup/Wednesday.img1            8192      122879       57344    c  W95 FAT32 (LBA)
/mnt/NetBackup/Wednesday.img2          122880    30703615    15290368   83  Linux

 

Jetzt kann man den Offset des Partitionsanfangs ausrechnen:

Sectorgröße * Startsektor = (in diesemFall) 512 * 122880 = 62914560

 

Vorbereiten des Images zum Mounten.

 

losetup -o 62914560 /dev/loop0 /mnt/NetBackup/Wednesday.img

 

Wenn man schon dabei ist kann man auch mal testen ob das Image in Ordnung ist:

fsck -fv /dev/loop0

fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
       96707 inodes used (25.17%, out of 384272)
          61 non-contiguous files (0.1%)
          90 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 80470/26
      998426 blocks used (65.00%, out of 1536000)
           0 bad blocks
           1 large file
       71985 regular files
        7931 directories
          56 character device files
          25 block device files
           0 fifos
        1172 links
       16701 symbolic links (16122 fast symbolic links)
           0 sockets
------------
       97870 files

Sieht gut aus, der Rest ist einfach.

 

Mounten des Images

 

mount /dev/loop0 /mnt/NetBackup/ImageMount

 

Der Mountpunkt sollte jetzt im System eingebunden sein.

 

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    1     4G  0 disk
└─sda1        8:1    1     4G  0 part /media/usb0
loop0         7:0    0  14.6G  0 loop /mnt/NetBackup/ImageMount
mmcblk0     179:0    0  14.7G  0 disk
├─mmcblk0p1 179:1    0    56M  0 part /boot
└─mmcblk0p2 179:2    0  14.6G  0 part /

 

Noch schneller wird man den Mount auf das gesicherte Image wieder los.

 

umount /mnt/NetBackup/ImageMount
losetup -d /dev/loop0

 

---

 

Automatisches mounten und lösen mit Skripten

 

Um nicht jedes Mal alles von Hand einzutippen kann man das auch über Skipte lösen.

Mit dem ersten Skript kann eine der sieben Wochentagssicherungen ausgewählt und automatisch gemountet werden.

 

/bin/scripts/mountbackup.sh

Welches Image soll gemountet werden?
Montag     (1)
Dienstag   (2)
Mittwoch   (3)
Donnerstag (4)
Freitag    (5)
Samstag    (6)
Sonntag    (7)
Auswahl:3

mounting File: /mnt/NetBackup/Wednesday.img to /mnt/NetBackup/ImageMount/
done....

 

Das Image vom Mittwoch steht jetzt zur Verfügung.

 

Nach Gebrauch einfach wieder lösen.

 

/bin/scripts/umountbackup.sh

unmount: /mnt/NetBackup/ImageMount/
done....

 

Um einen Überblick zu haben was gerade gemountet ist werden die Skiptereignisse geloggt.

 

cat /tmp/cron.log

4.10.2015-13:04:01 | start backup: /mnt/NetBackup/Sunday.img
 4.10.2015-13:04:01 | backup done
 4.10.2015-17:36:53 | unmounting DIR: /mnt/NetBackup/ImageMount/
 4.10.2015-17:37:44 | mounting File: /mnt/NetBackup/Wednesday.img to /mnt/NetBackup/ImageMount/
 4.10.2015-17:38:17 | unmounting DIR: /mnt/NetBackup/ImageMount/
 4.10.2015-20:02:27 | unmounting DIR: /mnt/NetBackup/ImageMount/
 4.10.2015-20:02:47 | mounting File: /mnt/NetBackup/Wednesday.img to /mnt/NetBackup/ImageMount/
 4.10.2015-20:06:02 | unmounting DIR: /mnt/NetBackup/ImageMount/
 4.10.2015-20:18:04 | mounting File: /mnt/NetBackup/Wednesday.img to /mnt/NetBackup/ImageMount/
 4.10.2015-20:23:22 | unmounting DIR: /mnt/NetBackup/ImageMount/

 

mountbackup.sh

#!/bin/bash

EventDate=$(date +%e.%m.%Y-%T)    

#Pfad zum BackupDirectory
#die Images müssen unter /mnt/NetBackup gesichert werden
#das Image wird dann nach /mnt/NetBackup/ImageMount gemountet
ImageDIR="/mnt/NetBackup/"
MountDIR="/mnt/NetBackup/ImageMount/"
#Offset angeben, mit -->  "fdisk -lu /image.img" Startsektor ermitteln
#Offset = Startsector * Sektorgröße
#z.B. 122880 * 512 = 62914560
StartSector="62914560"

#Image auswählen
echo ""
echo "Welches Image soll gemountet werden?"

echo "Montag     (1)"
echo "Dienstag   (2)"
echo "Mittwoch   (3)"
echo "Donnerstag (4)"
echo "Freitag    (5)"
echo "Samstag    (6)"
echo "Sonntag    (7)"

read -p "Auswahl:" Weekday

  case $Weekday in
    1) Weekday="Monday";;
    2) Weekday="Tuesday";;
    3) Weekday="Wednesday";;
    4) Weekday="Thursday";;
    5) Weekday="Friday";;
    6) Weekday="Saturday";;
    7) Weekday="Sunday";;
  esac
echo ""

Image="$ImageDIR$Weekday.img"
echo "mounting File: $Image to $MountDIR"
echo "$EventDate | mounting File: $Image to $MountDIR" 2>&1 >> /tmp/cron.log

#Image Mounten
losetup -o $StartSector /dev/loop0 $Image 2>&1 >> /tmp/cron.log
mount /dev/loop0 $MountDIR 2>&1 >> /tmp/cron.log

echo "done...."
lsblk

 

unmountbackup.sh

#!/bin/bash

EventDate=$(date +%e.%m.%Y-%T)    

#Pfad zum MountDirectory
MountDIR="/mnt/NetBackup/ImageMount/"

echo "$EventDate | unmounting DIR: $MountDIR" 2>&1 >> /tmp/cron.log

#Image UnMounten
umount $MountDIR 2>&1 >> /tmp/cron.log
losetup -d /dev/loop0 2>&1 >> /tmp/cron.log
echo "unmount: $MountDIR"

echo "done...."
lsblk

 

---

 

Rücksicherung des Images

 

Wenn denn doch mal zuviel murks passiert ist kann das gesicherte Image natürlich jederzeit mit Programmen wie dem Win32DiskImager wieder zurück auf die SD-Karte gespielt werden.
Aber auch die Live-Rücksicherung ist mit dd möglich.

dd if=/mnt/NetBackup/Wednesday.img of=/dev/mmcblk0

 

Da dd leider keine Fortschritsanzeige hat kann man in einem zweiten Terminalfenster folgen Befehl eingeben:

 

pkill -USR1 -x dd

 

In der ersten Konsole sollte jetzt der Fortschritt zu sehen sein.

 

354+0 records in
353+0 records out
370147328 bytes (370 MB) copied, 23.305 s, 15.9 MB/s
1226+0 records in
1226+0 records out
1285554176 bytes (1.3 GB) copied, 133.502 s, 9.6 MB/s
1240+0 records in
1240+0 records out
1300234240 bytes (1.3 GB) copied, 135.486 s, 9.6 MB/s

 

Nach der Rücksicherung muss der PI einmal durchgestartet werden..........

 

 

---

 

Links zum Thema

 

https://linuxundich.de/raspberry-pi/linux-images-fuer-den-raspberry-pi-auf-sd-karte-installieren/https://www.bitblokes.de/2013/03/sd-karte-des-raspberry-pi-sichern-dd-oder-partclone/http://raspberry.tips/raspberrypi-einsteiger/cronjob-auf-dem-raspberry-pi-einrichten/
https://wiki.ubuntuusers.de/ddhttp://madduck.net/blog/2006.10.20:loop-mounting-partitions-from-a-disk-image/
http://www.pcwelt.de/ratgeber/Linux-Praxis-Konsolen-Know-how-8298473.htmlhttps://freetux.wordpress.com/2007/12/23/systembackup-mit-dd/http://www.forum-raspberrypi.de/Thread-von-8gb-image-auf-2gb-image-verkleinernhttp://sirlagz.net/2013/03/10/script-automatic-rpi-image-downsizer/