solved: 3x Ausführung im Log - schaltet aber gar nicht

[Homoran]

@ch90045 echt strange!

da würde ich jetzt wirklich die Kiste rebooten

[paul53]

@ch90045 sagte: Danach

Das statische Datenpunkt-Objekt ändert sich nicht durch "steuere".

@ch90045 sagte: der Boiler ist an und war vorher aus. Es gab auch nur einen Logeintrag

Dann schalte den Boiler aus und packe die beiden Blöcke in einen Zeitplan, der in Kürze triggert.

[ch90045]

@paul53

Läuft, aber war ja auch mit den anderen jobs im orginal Blockly der Fall - neu ist, dass nur ein Logeintrag auftaucht

[Homoran]

@ch90045 root user.?
warum?

[paul53]

@ch90045 sagte: neu ist, dass nur ein Logeintrag auftaucht

Das hat sicherlich der Neustart von ioBroker bewirkt. Das Skript wird nun wahrscheinlich auch um 6:00 Uhr funktionieren.

[ch90045]

@homoran warum nicht?

[Homoran]

@ch90045 sagte in 3x Ausführung im Log - schaltet aber gar nicht:

@homoran warum nicht?

weil das die Rechte verbiegen kann, dass der Systemuser iobroker Probleme bekommt.

Bitte als normaler user einloggen und dann

iobroker stop
iobroker fix
iobroker start

nacheinander ausführen um die Rechte wieder zu fixen.

[ch90045]

@homoran auf dem System gibt es keinen anderen user

[BananaJoe]

Öhm, wenn er Debug-Einträge aus dem Blockly-Skript hat ist auch der Debug Modus im Editor an.
Wie dann da schon irgendwo als Meldung steht schaltet er im Debug Modus nicht wirklich sondern schreibt nur.

Also, ist der Debug Modus an? Wenn ja => ausschalten und dann sollte es auch gehen.

[ch90045]

@bananajoe was soll gehen? Drei croneinträge im gleichen blockly gehen nur einer nicht, alle haben den gleichen Debug Haken.

[Homoran]

@ch90045 sagte in 3x Ausführung im Log - schaltet aber gar nicht:

@homoran auf dem System gibt es keinen anderen user

dann leg einen an

[Homoran]

@bananajoe sagte in 3x Ausführung im Log - schaltet aber gar nicht:

wenn er Debug-Einträge aus dem Blockly-Skript hat ist auch der Debug Modus im Editor an.

wieso?
wenn der debug Block auf debug gestellt wäre, landet es im log auch als debug.

Aber wo siehst du das?

[BananaJoe]

@ch90045 ok, ich hab die bisherigen Post nicht genau genug gelesen und interpretiert das keiner von denen geht

[Wildbill]

@ch90045 sagte in 3x Ausführung im Log - schaltet aber gar nicht:

@homoran auf dem System gibt es keinen anderen user

Da sollte man aber wissen, dass man sich niemals als root anmeldet und immer mit einem normalen User, der bei Bedarf erweiterte Rechte bekommt, wenn das hier stimmt:

@ch90045 sagte in 3x Ausführung im Log - schaltet aber gar nicht:

@paul53 Paul, ICH weiss das Ich arbeite seit 1999 mit Solaris/Linux

Gruss, Jürgen

[BananaJoe]

@homoran sagte in 3x Ausführung im Log - schaltet aber gar nicht:

@bananajoe sagte in 3x Ausführung im Log - schaltet aber gar nicht:

wenn er Debug-Einträge aus dem Blockly-Skript hat ist auch der Debug Modus im Editor an.

wieso?
wenn der debug Block auf debug gestellt wäre, landet es im log auch als debug.

Aber wo siehst du das?

Ich habe mich total verguckt, war am Thema vorbei was ich geschrieben hatte

[ch90045]

@wildbill Ich bin mir durchaus bewusst, was der root user ist und ich habe mich bewusst für den root user entschieden. Das system ist nur in meinem LAN erreichbar und nur ich komme auf das System - ich sehe die Problematik nicht.

Bei einem Multiuser Systems wäre ich mit dem user root vorsichtiger - hier sehe ich keine Notwendigkeit.

[Wildbill]

@ch90045 Dann hast Du die ganzen Jahre aber nicht verstanden, worum es geht. Es geht nicht nur um das Thema Sicherheit (oder erst in zweiter Instanz) sondern einfach darum in welchem User-Kontext was läuft. Iobroker ist mittlerweile seit geraumer Zeit darauf ausgelegt, als user iobroker in ganz normalem User-Kontext zu laufen. Bei Bedarf holt sich dieser User (unter Linux) per sudo erweiterte Berechtigungen. Wenn Du da jetzt als root angemeldet bist und so beispielsweise iobroker administrierst oder Ordner oder Dateien anlegst, oder einen Adapter installierst, so übernehmen die neuen Dateien logischerweise die Berechtigungen von root. Dass Dir das dann irgendwann auf die Füße fällt, wenn der user iobroker darauf keinen Zugriff erhält, weil die Dateien eben root gehören, sollte nach so vielen Jahren Erfahrung offensichtlich sein. Zum Thema Sicherheit muss ich nichts sagen, root darf so gut wie alles, und damit natürlich auch alle Skripte und Programme, die in seinem Umfeld gestartet werden. Von obigem mal angesehen würde ich so ein System definitiv nicht in irgendein Netzwerk hängen, schon gar nicht mit möglicher Verbindung ins Internet. Das sollte "einem Profi" auch klar sein.
Also entweder flunkerst Du mit der jahrzehntelangen Erfahrung mit Solaris/Linux, wurdest da ursprünglich von Jemandem ausgebildet, der so absolut keine Ahnung hatte und nie was dazugelernt, oder ignorierst mit purer Absicht alles, was von Anfang an als best practice gilt.

Sei es, wie es ist, wer sich als root anmeldet, nicht versteht, warum das eine ganz schlechte Idee ist, der hat es nicht verstanden und verdient es vermutlich, früher oder später auf diverse Probleme zu stoßen.

Wer sich bewusst dazu entschieden hat, der hat irgendwo irgendwas gewaltig missverstanden!

Gruss, Jürgen

[ch90045]

@wildbill Erkläre mir mal bitte, wie root den Zugriff auf Objekte verlieren sollen, die root gehören ...

Ob du in der Position bist, über meinen beruflichen Werdegang von 1999-2011 bei Sun Microsystems und danach bei NetApp im technischen Support urteilen kannst, überlasse ich dir selber, habe aber meine eigene Meinung drüber. Danke für deinen Input "offtopic" zu dem Orginalthema.

[Wildbill]

@ch90045 Ich habe nicht gesagt, dass root den Zugriff auf seine eigenen Objekte und Dateien verliert, sondern dass zum Beispiel der user iobroker, unter dem iobroker auf Linux-Installationen numal mittlerweile läft, eben auf solche Objekte nicht zugreifen kann. Wie oft gab es hier im Forum Hilfe-Threads, weil es eben Probleme gab, da zum Beispiel Node und NPM als root ins System geprügelt wurden, Pfade nicht passten usw. Nicht umsonst versucht der Befehl ```
iobroker fix

das gerade zu biegen und benötigte Pfade für iobroker wieder zugänglich zu machen. Bringt aber auch nix, wenn die Grundlagen eben falsch (als root) installiert wurden.

BTW, Ich glaube kaum, dass sich bei un Microsystems oder NetApp als root eingeloggt wird. Wenn, dann würde für mich jetzt eine Welt zusammenbrechen.

Und ich denke nicht, das ist hier offtopic. Bei wie vielen "root-Installationen" hier im Forum tauchen immer wieder die gleichen Probleme auf? Geisterprozesse, weil der user iobroker nicht mehr ran kommt, Skripte, die nicht so laufn, wie sie sollen, kein Zugriff auf irgendwelche Dateien usw.

Bevor man ins Detail geht, sollte man die Grundlagen erledigt haben, und dazu gehört eine saubere Installation. Und die findet sicher nicht als root statt. Ganz einfach.
Und jetzt mögen Dir andere helfen bei Deinem Problem, vielleicht findet sich ja noch etwas Erhellendes.

Gruss, Jürgen

[ch90045]

@wildbill den Nutzer iobroker gibt es nunmal hier nicht, ergo hat der auch keine Probleme auf Objekte zuzugreifen.

Verstehe mich nicht verkehrt, aber missionarisch hier jemanden anzugehen, ohne einen konkreten Hinweis auf "genau ist das Problem" zu liefern, finde ich eher oberflächlich. Im beruflichen Umfeld erwartet ein Kunde einen Hinweis auf: Das haben wir festgestellt, das ist das Problem, so stellt man das ab. Ja, das erwarte/erhoffe ich hier nicht - ganz klar nicht, reagiere bloss ein wenig genervt auf - "das ist es bestimmt, weiss zwar nicht warum, aber best practices sagen, dass man das so machen soll"