NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
Bitte keine Screenshots und den Raspberry NICHT MIT DESKTOP BETREIBEN!
-
Bitte keine Screenshots und den Raspberry NICHT MIT DESKTOP BETREIBEN!
-
OK wie mache ich das denn richtig?
Per ssh in einem Terminal auf den Pi gehen. puTTY oder die Windows Powershell nimmt man dafür z. B.
Den Pi betreibt man im sog. RunLevel 3. -
@martin-0 said in [Linux Shell-Skript] WLAN-Wetterstation:
Das sieht mir nach einem Formatierungsproblem aus. Da sind mir zu viele Leerzeilen drin.
Direkt nach den Überschriften sollten die Argumente kommen, da ist aber überall eine Leerzeile, evtl. hat der systemd ein Problem damit. -
@martin-0 said in [Linux Shell-Skript] WLAN-Wetterstation:
Das sieht mir nach einem Formatierungsproblem aus. Da sind mir zu viele Leerzeilen drin.
Direkt nach den Überschriften sollten die Argumente kommen, da ist aber überall eine Leerzeile, evtl. hat der systemd ein Problem damit.Oder die Datei ist mit einem Windows-Editor vermurkst worden und hat keine Linux-Zeilenumbrüche.
-
@martin-0 said in [Linux Shell-Skript] WLAN-Wetterstation:
Das sieht mir nach einem Formatierungsproblem aus. Da sind mir zu viele Leerzeilen drin.
Direkt nach den Überschriften sollten die Argumente kommen, da ist aber überall eine Leerzeile, evtl. hat der systemd ein Problem damit.@viper4iob
Ich habe jetzt alle Leerzeichen gelöscht.
Keine Veränderung -
Oder die Datei ist mit einem Windows-Editor vermurkst worden und hat keine Linux-Zeilenumbrüche.
@thomas-braun
Den habe ich garnicht benutzt. -
@thomas-braun
Den habe ich garnicht benutzt. -
Deutet der Fehler nicht eher daraufhin, dass die Datei garnicht gefunden wird bzw nicht ausführbar ist?
-
-
pi@raspberrypi:~ $ ls -la /home/iobroker/wetterstation.sh -rwxr-xr-x 1 root root 15472 Nov 3 09:40 /home/iobroker/wetterstation.sh
Mod-Edit: Code in </> Code-Tag gepackt!
-
@martin-0
Es lag an der Formatierung.Ich habe Leerzeilen eingefügt zwischen den Befehlen. Jetzt geht es.
@martin-0
Das klingt dann danach, dass die Zeilenumbrüche nicht gepasst haben.
Linux nutzt LF und Windows CRLF und wenn man das irgendwie von Windows rüber holt, hat man evtl. die falschen.
Da gibt es dann z.B. das Kommando dos2unix, um das umzuwandeln.
Und wenn man die Zeilenumbrüche he dem Editor unter Linux wieder einfügt, nimmt er natürlich LF
Du hast also vorhin beim Löschen der Leerzeilen wahrscheinlich die falschen gelöscht und dann durchs einfügen, die richtigen hinzugefügt. -
pi@raspberrypi:~ $ ls -la /home/iobroker/wetterstation.sh -rwxr-xr-x 1 root root 15472 Nov 3 09:40 /home/iobroker/wetterstation.sh
Mod-Edit: Code in </> Code-Tag gepackt!
Die Datei in /home/iobroker sollte aber NIE dem root gehören.
-
Die Datei in /home/iobroker sollte aber NIE dem root gehören.
@thomas-braun
Ich habe alles mögliche umgestellt.
Warum denn nicht? -
@thomas-braun
Ich habe alles mögliche umgestellt.
Warum denn nicht?@martin-0
Weil das das /home des iobrokers ist. Und nicht vom root. Der wohnt unter /root. -
@thomas-braun
Ich habe alles mögliche umgestellt.
Warum denn nicht?@martin-0
Kannst du mal das machen :
cat -e /etc/systemd/system/wetterstation.serviceDer sollte den Inhalt der Datei mit Zeilenumbrüchen darstellen. Ich hoffe auch CRLF, falls vorhanden.
Was kommt da raus?
Es geht zwar jetzt, aber diese Leerzeilen gehören da eigentlich nicht hin. Evtl. hast du jetzt beide Typen drin.EDIT
Er müsste $ für LF anzeigen, was richtig wäre.
Und ^M$ für CRLF. Die sollten da nicht auftauchen. -
@thomas-braun
Ich habe alles mögliche umgestellt.
Warum denn nicht?sudo chown iobroker:iobroker /home/iobroker/wetterstation.sh -
@martin-0
Kannst du mal das machen :
cat -e /etc/systemd/system/wetterstation.serviceDer sollte den Inhalt der Datei mit Zeilenumbrüchen darstellen. Ich hoffe auch CRLF, falls vorhanden.
Was kommt da raus?
Es geht zwar jetzt, aber diese Leerzeilen gehören da eigentlich nicht hin. Evtl. hast du jetzt beide Typen drin.EDIT
Er müsste $ für LF anzeigen, was richtig wäre.
Und ^M$ für CRLF. Die sollten da nicht auftauchen.Zum Thema Dateirechten und Besitzerschaft vom Skript:
Im Prinzip gebe ich @Martin-0 recht. Wenn man das Skript im Home vom iobroker betreibt, sollte es auch iobroker gehören.
Aus Sicherheitssicht spielt es aber keine große Rolle, denn sobald das Skript als systemd Service gestartet wird, läuft es unter root. Kann man beispielsweise mitps -ef | grep wetterstationkontrollieren.
Und das Risiko ist denke ich deutlich höher, falls eben jemand das Github Repository manipuliert und man sich diese Änderungen dann installiert.Wichtig wäre also meiner Meinung nach den Service unter einem anderen User als root ausführen zu lassen. Das Skript braucht soweit ich das aktuell feststellen konnte, für das normale Ausführen keine root-Rechte, es führt netcat aus und solange der Port über 1024 ist, braucht das keine root Rechte. Und dann kommuniziert es mit iobroker und die InfluxDB über deren Schnittstellen, was ebenfalls keine root Rechte benötigt.
Um den Service als anderer User zu starten muss man im Service File im Abschnitt [Service] die Argumente User und Group hinzufügen und da dann beispielsweise den iobroker angeben.
Ich hab es aktuell unter meinem eigenen User laufen.
Streng genommen sind beide User nicht optimal und man müsste einen komplett neuen User nur für das Skript anlegen, der sich auch nicht interaktiv anmelden kann und darüber dann den Dienst laufen lassen, aber das war mir dann auch zu viel des Guten.
Unter meinem User funktioniert es auf alle Fälle.
Über den iobroker User habe ich es noch nicht getestet. Der iobroker user wäre vielleicht aktuell sogar die bessere Wahl, weil der sich wahrscheinlich nicht interaktiv anmelden kann, also nur ein System User ist. Nur weiß man nie, ob sich da mit irgendeinem Update mal wieder was ändern könnte. Bis vor einiger Zeit lief der iobroker auch nicht unter eigenem User, das wurde dann irgendwann mal angepasst.@SBorg
Das wäre evtl. nochmal ein Punkt, worüber man für den Install Guide und der Service File Definition nachdenken könnte. Vielleicht auch einfach nur als Hinweis und man kann dann selbst entscheiden. -
Zum Thema Dateirechten und Besitzerschaft vom Skript:
Im Prinzip gebe ich @Martin-0 recht. Wenn man das Skript im Home vom iobroker betreibt, sollte es auch iobroker gehören.
Aus Sicherheitssicht spielt es aber keine große Rolle, denn sobald das Skript als systemd Service gestartet wird, läuft es unter root. Kann man beispielsweise mitps -ef | grep wetterstationkontrollieren.
Und das Risiko ist denke ich deutlich höher, falls eben jemand das Github Repository manipuliert und man sich diese Änderungen dann installiert.Wichtig wäre also meiner Meinung nach den Service unter einem anderen User als root ausführen zu lassen. Das Skript braucht soweit ich das aktuell feststellen konnte, für das normale Ausführen keine root-Rechte, es führt netcat aus und solange der Port über 1024 ist, braucht das keine root Rechte. Und dann kommuniziert es mit iobroker und die InfluxDB über deren Schnittstellen, was ebenfalls keine root Rechte benötigt.
Um den Service als anderer User zu starten muss man im Service File im Abschnitt [Service] die Argumente User und Group hinzufügen und da dann beispielsweise den iobroker angeben.
Ich hab es aktuell unter meinem eigenen User laufen.
Streng genommen sind beide User nicht optimal und man müsste einen komplett neuen User nur für das Skript anlegen, der sich auch nicht interaktiv anmelden kann und darüber dann den Dienst laufen lassen, aber das war mir dann auch zu viel des Guten.
Unter meinem User funktioniert es auf alle Fälle.
Über den iobroker User habe ich es noch nicht getestet. Der iobroker user wäre vielleicht aktuell sogar die bessere Wahl, weil der sich wahrscheinlich nicht interaktiv anmelden kann, also nur ein System User ist. Nur weiß man nie, ob sich da mit irgendeinem Update mal wieder was ändern könnte. Bis vor einiger Zeit lief der iobroker auch nicht unter eigenem User, das wurde dann irgendwann mal angepasst.@SBorg
Das wäre evtl. nochmal ein Punkt, worüber man für den Install Guide und der Service File Definition nachdenken könnte. Vielleicht auch einfach nur als Hinweis und man kann dann selbst entscheiden.@viper4iob Solange bspw. die "sh" root:root gehört und der User also das Ganze als root durchführt (weil es ja einfacher ist und man nicht dauernd ein Passwort eingeben muss, oder dauernd ein sudo nutzen muss... :man-facepalming: ) sehe ich es noch als "geringeres Übel" an. 99% der User werden auch einfach die "sh"s ausführen ohne vorher mal rein zu sehen. Wozu auch, verstehen eh nur die wenigsten und bei Windows sehe ich in der setup.exe eh nicht was am/im System passiert. Ihnen ist aber nicht bewusst, dass, wenn sie es als "root" ausführen, ich die volle Kontrolle über ihr Systems erlange. Wenn ich dies denn wollte, und nein liebe Mitleser, da brauche ich nicht mal was zu hacken.
Diese Gefahr besteht natürlich auch wenn man meinen GitHub-Account hackt. Deswegen announce ich auch neue Betas und Releases immer hier. So müsste er auch meinen Foren-Account hacken. Allerdings wird da nicht jeder darauf achten, und diejenigen die per Suche auf das GitHub-Repository stoßen sowieso nicht.Trotzdem könnte man es natürlich auch einfach als User-Service laufen lassen, gäbe es nicht wieder eine Ausnahme mit Protokoll #9. Dies läuft explizit (da es ein offizieller Web-Server sein muss) nur auf Port 80, sonst würde ich einfach keine Ports <=1024 mehr zulassen und könnte mich damit nur Userrechten zuwenden.
Die Idee mit einem extra unprivilegierten User hat aber was (iobroker mag ich aus den von dir schon genannten Gründen nicht). Dann müsste nur der Protokoll #9-Nutzer den Service halt mit root-Rechten laufen lassen.
Nutzt denn wer einen Port <=1024? Wenn ja, warum (außer Protokoll #9-Nutzer ;) ) ? Es gibt ~64.5k andere Ports :)
-
@viper4iob Solange bspw. die "sh" root:root gehört und der User also das Ganze als root durchführt (weil es ja einfacher ist und man nicht dauernd ein Passwort eingeben muss, oder dauernd ein sudo nutzen muss... :man-facepalming: ) sehe ich es noch als "geringeres Übel" an. 99% der User werden auch einfach die "sh"s ausführen ohne vorher mal rein zu sehen. Wozu auch, verstehen eh nur die wenigsten und bei Windows sehe ich in der setup.exe eh nicht was am/im System passiert. Ihnen ist aber nicht bewusst, dass, wenn sie es als "root" ausführen, ich die volle Kontrolle über ihr Systems erlange. Wenn ich dies denn wollte, und nein liebe Mitleser, da brauche ich nicht mal was zu hacken.
Diese Gefahr besteht natürlich auch wenn man meinen GitHub-Account hackt. Deswegen announce ich auch neue Betas und Releases immer hier. So müsste er auch meinen Foren-Account hacken. Allerdings wird da nicht jeder darauf achten, und diejenigen die per Suche auf das GitHub-Repository stoßen sowieso nicht.Trotzdem könnte man es natürlich auch einfach als User-Service laufen lassen, gäbe es nicht wieder eine Ausnahme mit Protokoll #9. Dies läuft explizit (da es ein offizieller Web-Server sein muss) nur auf Port 80, sonst würde ich einfach keine Ports <=1024 mehr zulassen und könnte mich damit nur Userrechten zuwenden.
Die Idee mit einem extra unprivilegierten User hat aber was (iobroker mag ich aus den von dir schon genannten Gründen nicht). Dann müsste nur der Protokoll #9-Nutzer den Service halt mit root-Rechten laufen lassen.
Nutzt denn wer einen Port <=1024? Wenn ja, warum (außer Protokoll #9-Nutzer ;) ) ? Es gibt ~64.5k andere Ports :)
Ich habe mal eine Frage Richtung Best Practice für das Thema iobroker, InfluxDB, Grafana.
Und zwar gibt es Datenpunkte, bei denen nur der aktuelle Wert eine Rolle spielt, wie z.B. Letzte_Regenmenge. Aus Sicht iobroker macht es keinen Sinn diese als Historie in der InfluxDB mitzuschreiben.
Damit der Wert aber in Grafana angezeigt werden kann, muss man es doch tun.
Da sich der Wert nicht so oft ändert, lasse ich nur Änderungen in die DB schreiben, man muss ja nicht unnötig Daten schreiben, dachte ich.
Allerdings ist das nun für Grafana ein ziemliches Problem, denn Grafana zeigt Werte aus einem bestimmten Zeitraum an. Also beispielsweise die letzten 24 Stunden. Für einen Graphen ist das natürlich sinnvoll, aber oft will man ja nur den letzten aktuellen Wert anzeigen.
Und da kommen wir zum Problem: Wenn innerhalb dieses Zeitraums kein Wert in die InfluxDB geschrieben wurde, zeigt er gar nichts an, also NA bzw. No Data.
Muss ich jetzt wirklich im iobroker bei der Historie eines solchen Datenpunkts einstellen, dass der in festen Zeitabständen geschrieben wird, damit das in Grafana angezeigt wird?
Wenn man das auf die Spitze treibt und ich in Grafana mal den Zeitraum auf 5 min stellen will, dann müsste man im iobroker einstellen, dass im Endeffekt alle 5 min der gleiche Wert geschrieben wird, nur damit es in Grafana angezeigt wird.
Das macht irgendwie keinen Sinn.
Was ist hier also sinnvoll?
Support us
672
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge