Ich möchte eine Diskussion angegen, die mir Antworten zu folgendem Thema gibt:
"Wie kann man die Funktion eines FHEM System auf einem Raspberry absichern, auf das man persönlich über längere Zeit (Monate) keinen physkalischen Zugriff hat"
Ich würde noch unterscheiden in 2 Szenarien:
1. Man hat keinen physikalischen Zugriff, auch nicht über FHEM/Computer unbedarfte Dritte
2. Es gibt Freunde, die max. in der Lage sind, einen oder mehrere Stecker umzustecken.
Es gibt ja verschiedene Fehlerszenarien, die auftreten können:
1. Flashkarte defekt
2. RPI defekt incl Zusatzteile
3. FHEM so zerschossen, dass es nicht mehr startet. (durch Manipulation über externen Zugriff)
4. RPI Basissoftware zerschossen [/code]
Es bleiben immer noch viele Möglichkeiten, die auftreten und man keine Möglichkeit hat einzugreifen. Diese will ich aktuell nicht betrachten.
1. Fritzbox defekt (ich mache die Installation heute so, dass ich den RPI direkt über Netzwerkkabel an der Fritzbox angeschlossen habe. Kein Router dazwischen.
2. etc
Merci vorab für eure Gedanken und Ausführungen
Ich betreibe seit vielen Jahren FHEM auf Routern. Seit kurzem bin ich auf eine x86 Platform gewechselt. Ich betreibe FHEM immer Headless (=ohne Monitor oder Tastatur).
Es gibt da natürlich viele Möglichkeiten solch eine Anforderung anzugehen. Ich möchte gerne folgende Punkte explizit vorschlagen:
- Ein RPi mit dem Betriebssystem von µSD-Karte hat einfach eine absehbare Schwäche. Bei einigen gehts jahrelang gut, bei anderen nicht. Empfehlung wäre zu einer anderen Hardware bei der das OS z.B. von eMMC gestartet wird. Bleibt man bei einem RPI, da man den nun bereits gekauft hat, dann sollte man sich mal USB Speicher genauer ansehen. Der elektrische Kontakt ist da IMHO zuverlässiger, die Auswahl an zuverlässigem Speicher größer. Als USB Speicher kommen SSD mit passenden Gehäuse in Betracht, oder hochwertige USB-Sticks.
- Idealerweise sollte das OS auf solch einem "Headless"-Server möglichst wenig Zugriffe auf das Bootmedium vornehmen. Meine Lieblingslösung basiert darauf, erstmal OpenWRT aufzuspielen und davon zu booten. OpenWRT bietet SSH Zugriff und nutzt das Bootmedium nur beim Start. Auch kann man solch einen OpenWRT-RPi JEDERZEIT abschalten, ohne dass das OS Schaden nimmt. Damit man trotzdem den Komfort eines nicht abgespeckten Betriebssystems nutzen kann, erstelle ich gerne ein Userland auf einem USB-Stick (siehe auch: https://forum.fhem.de/index.php?topic=134680.0). Alternativ kann man auch Docker oder LXC nutzen. Dort wird dann FHEM installiert, der Start von FHEM in dieser Umgebung erfolgt aus OpenWRT heraus.
- Alternativ kann man den Headless-Server (=hier der erwähnte RPi) mit einem IP-KVM verbinden. Die kosten nochmal extra, aber bieten Möglichkeiten den Headless-Server dann doch über IP so zu nutzen, als wenn man davor sitzt. Toll finde ich da PI-KVM, das bräuchte aber einen zweiten RPi und kostet extra.
- Sonst, falls der ganze Headless-Server kaputt gehen können soll, dann braucht man einfach ein Ersatzgerät und ein Backup. Sowas kann man auch als High-Availability-Lösung gestalten, aber ich denke nicht, dass das hier angemessen ist, oder? Man hätte dann praktisch immer zwei Server im Betrieb bei denen im Fehlerfall ganz schnell der Ersatzserver übernimmt falls mal was hakt.
- In deinem geschilderten Fall würde ich den RPi möglichst direkt mit dem Router verbinden, also kein Powerline, Switche oder WLAN dazwischen vorsehen. Das sind sonst alles zusätzliche Fehlerquellen.
Ich möchte empfehlen das "Basis-Betriebsystem" so zu wählen (=OpenWRT) oder zu konfigurieren (=nur Lesezugriff), dass immer gebootet werden kann und dann FHEM ganz regelmäßig sichern (als lokale Kopie zB als tar.gz und besser auch nach Extern). FHEM sollte auf einem anderem Datenträger laufen. Der Fernzuggriff läuft über SSH, was von zB. OpenWRT dann bereits angeboten wird und auch sehr zuverlässig immer wieder "hochstartet", selbst wenn man mal viele Stromausfälle hat, oder die Kiste immer an und ausschaltet.
So spontan fällt mir das dazu ein. Bin gespannt was die anderen so sagen...
Achso, und eine Unterbrechungsfreie StromVersorgung (USV) würde ich auch anraten. FHEM selbst hat durchaus Situationen in denen es nicht gut auf einen Stromausfall klarkommt. Für einen RPi bis zur Version 3 kann man günstig eine Powerbank mit "Passthrough" verwenden. Das ist günstiger als die spezieller RPi-USVs. Alternativ kann man eine USV für die 230V Seite beim Netzteil empfehlen, auch die würde ich den speziellen RPi-USVs vorziehen, da sie günstiger sind und vielfach nützlich weiterverwendet werden können. Wenn man es handwerklich hinbekommt, kann man gebrauchte USVs kaufen und muss ggf. nur den Akku erneuern.
Mein Konzept geht etwa so:
2 RPI's,
1) Produktiv-system
. nur FHEM + Mosquitto
2) Backup-system - auch "load sharing"
. alle "zusätzlichen" Services eg. Datenbank(mySQL), Mosquitto, OWServer, knxd, ebusd, grafana, shell scritpts die extene Webseiten abfragen-daten via MQTT an FHEM schicken, ...
. FHEM mit identer Konfig vorhanden, allerdings NICHT gestartet
Beide Systeme an einen NW-Switch, mit USV abgesichert - als sekundäres IF WLAN.
-keine USB/Seriell/GPIO Verbindungen an den systemen, also CUNO stat CUL, KNX-Router statt TUL, EBUS via LANGW,mySENSORS LAN-GW, falls nicht anders möglich mittels Seriell2Net HW,...
-Alle RPI's und externe "Sensoren" mit statischen IP-Addr - (bei Ausfall des Routers(DNS) geht noch immer alles innerhalb des Netzes.)
Zugriff vom Internet: nur via VPN
Ein keepalive monitored das aktive- und das BU-system - falls FHEM nicht reagiert - kill pid und restart
- falls NW-Fehler - starten FHEM auf Backup-system
Alle "zusätzlichen Services" können auch auf dem primären system gestartet werden (manuell), das hat sich bei HW / Betriebssystem neu Installation schon besten bewährt.
Wöchentlich wird auf jedem system eine IMG-kopie erstellt (auf USB-Stick-Flashcard), diese wird anschießend auf ein NAS kopiert...
Beim nächsten HW-Tausch wird vmtl. ein system mit SSD eingesetzt werden - ganz ohne flashcard...
Weitere Überlegung: statt der Backup-Wlan Verbindung jeweils ein 2.Lan IF einbauen - auf einen BU-switch...
Das ganze macht natürlich nur Sinn, wenn nicht ständig konfig-änderungen passieren....
l.g.erwin
Wenn man wirklich "vor Ort" jemanden hat, der "Stecker stecken kann", kann man im Notfall auch einfach ein fertiges Boot-Medium zusenden.
Ein "echter" Hardwaredefekt ist zwar auch möglich, aber eher selten. Meistens geht die Installation durch Adminfehler (oder der erwähnte Stromausfall) kaputt, so das man nicht mehr zugreifen kann. Optimal ist so ein Reservebootmedium schon vor Ort vorhanden und man muß es eben nicht (s.o.) zusenden. Solange kam per ssh auf den Rechner zugreifen kann, ist häufig eine Lösung gegeben.
Danke für die bisherigen Antworten. Teilweise finde ich mich wieder.
In meinen einfachen Worten stelle ich mir Folgendes vor:
Ich richte vor dem Weggehen 2 identische RPI incl Zubehör mit identischen Flashkarten her.
Beide schließe ich an fernsteuerbare Steckdosen an, den ProduktionsRPI noch zusätzlich über eine Passthrough Powerbank.
Beim Verlassen der Lokation ist der ProduktionRPi eingeschaltet, der ReserveRPI ist ausgeschaltet. Im Fehlerfall, möglicherweise 2 Monate später, schalte ich den ProduktionsRPI per Fernschaltung aus und der Reserve RPI ein und hoffe..
Unsicher bin ich, ob es da Konfigurationen, Datenbanken etc. innerhalb der 2 Monate auf dem ProduktionsRPI entwickelt haben und die der ReserveRPI nicht kennt und damit aufläuft. Alexa, Logfiles, etc..
Ich werde in meiner Abwesenheit keine FHEM Änderungen an dem System durchführen, keine Updates etc. Darauf läuft nur Hausautomatisierung.
Zitatkeine Updates etc.
Wobei ich bei Betriebsystemupdates da schon wieder meine Schwierigkeit habe .. wenn sich ich gleichen Netz Rechner mit Internetzugriff befinden, würde ich durchaus remote "normale" Updates machen ...
Hallo Wernieman,
lass mich dies noch verstehen:
Ich habe im selben Netz einen Rechner mit Internetzugriff und habe auch einen Zugriff mit Kitty. Getestet hab ich das noch nicht. Du meinst also , dass ich das Betriebssystem des ProduktionsRPI Remote updaten soll. Ich hätte dies als kritisch eingestuft.
Der ReserveRPI ist ja nicht im Zugriff und verbleibt dann auf dem alten Betriebssystemstand.
Warum würdest du dann nur das Betriebssystem und nicht auch FHEM regelmäßig updaten? Und welchen Zeitraum würdest du als regelmäßig einschätzen?
Die Dauer zwischen 2 ,,lokalen Besuchen" von mir mit dann physikalischem Zugriff auf die RPIs würde ich auf Max. 4 Monate schätzen.
Du hast 2 Problemfelder:
1. Zugriff auf dem Pi
2. Höhere Funktionen, wie FHEM
Dabei ist 1. das Kritische. Solange Du mit ssh von der Ferne auf den Pi kommst, kannst Du (die meisten) Softwarefehler ausbügeln. Erst wenn der Remotezugriff "weg" ist, hast DU ein Problem, dann aber richtig.
Ein "normales" Update, also nicht Dist-Upgrade, ist relativ unkritisch, wenn man sich die Veränderungen VORHER ansieht. Dafür erhöhen sie die Sicherheit gegen Ausnutzung von Fehlern.
Aus der Ferne kannst Du in Notfall z.B. auch ein Backup von FHEM einspielen (wenn vorhanden) ... wenn eben 1. gegeben ist.