Hallo zusammen,
ich bin aktuell dabei die FHEM Logs (und auch Logs anderer Pi) auf das NAS umzuleiten um die SD zu schonen.
Jetzt stell sich mir die Frage: Wieso nicht gleich das ganze /opt/fhem/ auf das NAS umziehen? Eine Antwort bleibe ich mir aber schuldig...
Daher die Frage an euch: Macht das Sinn? Keinen Sinn?
Die Frage ist seltsam gestellt. Was möchtest du tun? FHEM auf dem NAS laufen lassen oder das FHEM Verzeichnis auslagern? Ich würde FHEM auf dem Raspberry Pi belassen und ggf. Backups auf das NAS schieben. FHEM läuft zwar auf NAS Systemen grundsätzlich auch (da wäre es tatsächlich sinnvoll zu wissen, um was für ein NAS es sich handelt), es ist aber meist deutlich aufwendiger, einzurichten.
Bitte mehr Infos liefern.
Wenn Du willst, könntest Du das komplette FHEM-Verzeichnis auf das NAS schieben. Aber was ist, wenn das NAS mal nicht erreichbar ist?
Dieses ist nicht mal sooo unwarscheinlich:
z.B. Stromausfall, Strom kommt wieder und beide Gerät fangen an zu booten. Meiner Erfahrung nach ist der RasPi schneller als das NAS .... damit kein FHEM
Das mit der Boot-Time ist ein gutes Argument... Damit hat sich das Auslagern des ganzen FHEM-Dir schon erledigt...
Laeuft denn FHEM wenn das Log-Dir "noch" nicht da ist?
Ich hab das ähnlich gelöst - FHEM auf RPI2, Logs und Backups auf einem NAS im Netzwerk. Funktioniert seit einem Jahr tadellos. FHEM an sich auslagern - wozu, da sehe ich wenig Sinn, es sei denn man möchte den PI abschaffen?!
ich würde die logs auf dem raspi schreiben und regelmäßig (täglich) auf das nas sichern.
Wobei ich den Sinn des Vorhabens, die fhem-Verzeichnisse auf verschiedene Hardware zu verteilen, in diesem Leben vermutlich nicht mehr verstehen werde.
Sinn der Log Auslagerung soll die Reduzierung des SD-Karten Verbrauchs sein. Hatte ich auch so im Eingangspost erwaehnt.
Hier muss man klar abwägen. Das loggen ist für einigermaßen brauchbare SD Karten gar nicht so schlimm. Das man hier im FHEM-Forum so übermäßig oft von angeblich abgerauchten SD-Karten liest, hängt, meiner Meinung nach, mit anderen Problemen, als dem reinen loggen zusammen. Eines meiner Testsysteme (für viele Aufgaben, nicht nur FHEM) loggt seit 3 Jahren unglaublich viel auf seine SD-Karte und es ist noch immer die erste. Hier sollte man eher schauen, dass man eine hochwertige SD-Karte verwendet UND nur das logged, was man auch wirklich benötigt. Zusätzlich würde ich eine Backup-SD bereit legen, die einen annähernd aktuellen Stand enthält. Das Problem/die Probleme, welches mit Auslagern entstehen kann/können, ist/sind wohl wahrscheinlicher, als ein Problem mit einer SD-Karte. Am Ende muss das natürlich aber jeder selbst wissen.
Hm... ich glaube ich werde es mal wagen nur das LOG-Dir auszulagern... Mal sehen in wie weit das zu Problemen fuehrt...
Wie gesagt, bei mir bislang ohne jegliche Probleme. Zum Warum - weil das NAS eh den ganzen Tag läuft, denn können die Logs auch dort geschrieben werden - und ich mach mir eben keine Gedanken mehr um SD-Karten oder Sticks. Selbst hochwertige Sticks sind mir schon nach einem halben Jahr abgeraucht - da hatte ich schlicht und ergreifend keinen Bock mehr zu.... ;)
Bei mir laufen unbeaufsichtigte fhem Installation in einigen Ländern seit Jahren ohne Probleme mit der SD-Karte der Erstinstallation.
An das Märchen "Loggen macht die SD Karte kaputt" habe ich noch nie geglaubt. Genausowenig wie an einen Stromausfall als Ursache.
ansonsten gäbe es noch die "performance" Variante
Loggen auf ein NAS mit der Unterstützung von RAM Log, da kommt alles zu erst in den RAM Cache und wird dann alle 24h (bestimmt auch konfigurierbar) einmal auf das "reale" Verzeichnis geschrieben
PS.: Ich teste auch gerade einen Raspi nur noch von der SD zu booten und dann komplett via Netz auf einem nfs bzw iscsi Device weiter zu machen. Bin aber noch ganz so weit :-)
Zitat von: betateilchen am 24 Juni 2016, 10:41:04An das Märchen "Loggen macht die SD Karte kaputt" habe ich noch nie geglaubt.
ich auch nicht. Denn sind 2 SDs gestorben, also hab ich nen Stick verwendet. Denn ist der gestorben, seitdem logge ich aufs NAS und die Welt ist schön ;)
ZitatLoggen auf ein NAS mit der Unterstützung von RAM Log, da kommt alles zu erst in den RAM Cache und wird dann alle 24h (bestimmt auch konfigurierbar) einmal auf das "reale" Verzeichnis geschrieben
Das wiederum klingst spannend, wenngleich ich den Turnus kleiner setzen würde. Gibts da ne Guideline? Nutzt Du ein Ramdrive auf dem RPI? Und, zuguter letzt, lässt sich das inkrementell anhängen - ich finde Monatslogs ganz praktisch... ;)
Mal als Zwischenfrage: nutzt Du 100% des Speicherplatzes Deiner SD-Karten und USB-Sticks, und welches Dateisystem dazu?
Ciao, -MN
Filesystem ist ext4. Platz ist reichlich (Status mit externen Logs auf NAS):
(http://pic-hoster.net/thumb/64264/SDCard.JPG) (http://pic-hoster.net/view/64264/SDCard.JPG.htm)
Zitat von: Wuppi68 am 24 Juni 2016, 11:10:04
Ich teste auch gerade einen Raspi nur noch von der SD zu booten und dann komplett via Netz auf einem nfs bzw iscsi Device weiter zu machen.
Wo siehst Du dabei Probleme? Ich hab das grade mal mit zwei debian-VMs getestet, das hat problemlos funktioniert. Eine VM hat /opt per nfs von der zweiten VM eingebunden.
Zitat von: betateilchen am 25 Juni 2016, 13:07:15
Wo siehst Du dabei Probleme? Ich hab das grade mal mit zwei debian-VMs getestet, das hat problemlos funktioniert. Eine VM hat /opt per nfs von der zweiten VM eingebunden.
Grundsätzlich sehe ich da keine Probleme, nur habe ich es noch nicht gemacht :-) Ich habe halt noch keine Umgebung, wo ich es einfach mal eben so Testen kann .... brauch noch dazu ein wenig Zeit :-)
So long
Ralf
Zitat von: Wuppi68 am 26 Juni 2016, 01:27:31
Grundsätzlich sehe ich da keine Probleme, nur habe ich es noch nicht gemacht :-) Ich habe halt noch keine Umgebung, wo ich es einfach mal eben so Testen kann .... brauch noch dazu ein wenig Zeit :-)
Seit heute mounten meine drei fhem-Installationen hier ihr /opt von einem nfs-Server. Funktioniert bisher völlig problemlos. Damit liegen die fhem-Installationen nun einschließlich ihrer configDB und Log-Datenbanken physikalisch alle auf einer "echten" HDD, die per sata an meinem zentralen cubietruck angeschlossen ist. Nachdem der cubietruck selbst ja derzeit kein eigenes fhem mehr ausführt, war es naheliegend, ihm andere Aufgaben zu übertragen. Dazu vielleicht irgendwann an anderer Stelle mal mehr.
wenn du schon so eifrig testest, vielleicht hast du ja auch eine Antwort auf folgende Frage:
was macht fhem wenn sein per smb/cifs/nfs gemountetes log-dir wegfällt? zB wegen reboot des NAS
und wenn es das überlebt, was wenn das Share dann wieder zurück ist? Stichwort automount
8)
markus
Genau wegen solcher Antworten von Leuten, die immer erstmal alles schlechtreden müssen und Probleme beschreiben, wo es keine gibt, vergeht mir immer öfter die Lust, hier überhaupt noch Antworten zu schreiben.
Ich habe gerade den Rechner, der die gesamten Datenbanken für die fhem-Installtionen bereitstellt, einmal durchgestartet. Das hat die laufenden fhem Systeme überhaupt nicht beeindruckt. Lediglich die während des reboot auflaufenden Events wurden nicht geloggt, aber das ist in meiner Konfiguration kein Problem. Meine Hausautomation ist nicht von geloggten Daten abhängig, die sind nur "nice-to-have" und werden ohnehin nach drei Tagen gelöscht.
Danke :)
Hast Du beim NFS Clientseitig das Caching eingeschaltet?
Eventuell könnte man dadurch Donwtimes unter 3 Sec. "ausgleichen" ...
Bei mir werden die Logs auf eine WDMyCloud im Netzwerk geschrieben. Wenn die neu bootet - und die braucht wirklich lange - affektiert das das System nicht. Es fehlen halt die Logs in dem Zeitraum, das war es denn auch.
Ich habe es jetzt wie folgt geloest:
- mount des shares
- symlink des /opt/fhem/log zum NAS
- mount -a alle 10 Minuten
Zitat- mount des shares
- symlink des /opt/fhem/log zum NAS
- mount -a alle 10 Minuten
Ich kann mit allem "leben", aber warum ein "mount -a alle 10 Minuten"?
vemutlich aus dem Irrglauben, dass man damit ein "gestorbenes" NAS nach seiner Wiederkehr automatisch wieder mounten könnte 8)
bestimmt ;o)
Aber dafür gibt es (z.B. bei NFS) Mountoptionen .. die dafür besser geeignet sind
jaja, laestert nur :P
??? Ich wollte nicht Lästern ???
Da ich nicht weiß, wie Du verbunden hast, kann ich Dir auch nicht pauschal sagen, wie Du es besser machen könntest, weshalb ich einfach gefragt habe (siehe mein Post von 14:32:05)
Und als "Beruflicher-Linux-Admin" habe ich eher die Befürchtung, das ein "mount -a" alle 10 Minuten nur Nachteile bringt. Warum sollte ich Dich "ins offene Messer" laufen lassen?
P.S. Es gibt zwar bessere Lösungen als Deine hier geschriebene (Punkt 1-2), aber bei Unix (Linux) führen eben mehrere Wege ans Ziel ...
ich bin hauptberuflicher forensiker :) so, jetzt kann ich zwar spuren lesen, aber keine legen.
ich habs per CIFS in der FSTAB gemountet.
//schubidu/RasPi /mnt/schubidu cifs username=blub,password=blah 0 0
Zitat von: micomat am 06 Juli 2016, 15:54:30
ich habs per CIFS in der FSTAB gemountet.
brrrr....
erstens ist cifs gruslig und zweitens heißt es fstab
ruhig brauner ;D
O.K. cifs kennt kein Automatisches remounten ...
nur mal so als Info:
Was cifs kann, einfach mal per man:
man mount.cifs
P.S.
Also in den "beliebten" Amerikanischen Filmen können Forensiker immer alles ... und Du nicht?
Bin aber jetzt seeehr entäuscht :o
(Achtung Ironie 8) )
Edit:
Übrigens kann der systemd auch mounten und kann sogar abgebrochene Verbindungen wieder aufbauen. Ist eventuell die Bessere Lösung
Habe hier mal mit Kollegen darüber "gequatscht" und die Einhellige Meinung: Ein "mount -a" ist eher negativ.
Wenn Du mal (per Hand) ein Mount ungemountet hast (z.B. Dateisystemcheck), schlägt nach X-Minuten der "mount -a" zu und Du hast ein Problem ..
danke fuer die info :)
werde mir systemd und Co. mal ansehen.
markus
PS: leider bin ich kein ami, sonst koennte ich sicherlich auch innerhalb von 10minuten DNA-Analysen machen ;D ;D ;D