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

[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"

[Wildbill]

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

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

Doch, genau den gibt es, wenn Du iobroker installiert hast und nicht gerade eine jahrzehntealte Installation hast. Der wird bei der Installation von iobroker direkt mit angelegt. iobroker läuft unter dem user iobroker, den gibt es sicher auch bei Dir. Der ist aber nicht zum Anmelden, sondern in dessen Kontext läuft halt iobroker. Aber eben nur sauber, wenn man nicht alles per root installiert hat, sonst kommt dieser user iobroker eben nicht überall ran.

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"

Was meinst Du, warum hier in jedem Thread, in dem sich herausstellt, dass sich jemand (grundsätzlich) als root anmeldet als erstes darauf hingewiesen wird, einen normalen User anzulegen, diesen in die Gruppe iobroker aufzunehmen und sich dann mit diesem anzumelden und erst einmal den Fixer auszuführen, bevor man weitere Problemlösungen angeht. Es bringt nix, sich in einem verbogenen System auf die Problemlösungssuche zu begeben, wenn schon das Grundgerüst schief ist.
Unter Linux ist es halt der normale Weg, sich einen User anzulegen, mit dem man arbeitet und der bei Bedarf z.B. per sudo erweiterte Rechte bekommt. Wobei das bei Allem, was mit iobroker zu tun hat, nie nötig ist.
Wenn Du das anders siehst, kannst Du das gerne so machen, darfst aber dann eben hier nicht um Hilfe bitten. Klick mal oben auf Docu, lies Dir die Installationsanweisungen durch und schau, ob da irgendwo steht, man solle sich per root anmelden oder mit sudo arbeiten. Sicher nicht, sondern das Gegenteil.
Wenn Du einem Kunden helfen sollst und ihm einen Lösungsvorschag machst und der Kunde aber der Meinung ist, das zählt für ihn nicht, weil er es besser weiss, dann kannst Du auch nur nochmal darauf hinweisen, dass das falsch ist. Wenn er es dennoch so will, dann soll er es tun, aber nicht erwarten, dass Dein Produkt dann bei ihm tut was es soll. Ganz einfach.
Im Linux-Umfeld wird niemand ernsthaft einen root-Zugang (der bei den meisten Distributionen mittlerweile für die Anmeldung erst einmal gesperrt und manuell freigeschaltet werden muss) verwenden. Dafür gibt es das user-System, das verwendet man einfach. Dass das unter Windows nicht so funktioniert, wie es vielleicht sollte ist ein anderes Thema. Aber unter Linux funktioniert es perfekt, wenn man nicht mit Gewalt versucht, es besser zu wissen und das untergräbt. Du hast doch mit einer root-Anmeldung 0,0 Vorteile, aber 100e Nachteile. Also wo ist das Problem, einen User anzulegen, den in die passende(n) Gruppe(n) zu schieben und mit dem zu arbeiten. Für alles, was dann nicht funktioniert wird Dir hier sicher geholfen.
Wenn Du aber meinst, aus jahrzehntelanger Erfahrung eh alles besser zu wissen, so kann man davon ausgehen, Du bist Profi und brauchst hier doch eh keine Hilfe?!

Gruss, Jürgen

Gruss, Jürgen

[ch90045]

@wildbill Jürgen, noch immer - kein Hinweis auf Grund des Threads und deinen Fixierung auf root/iobroker - wir beiden werde wohl nicht zueinander finden. Ich danke dir für deinen Input und wünsche dir eine ruhige Weihnachtszeit.

Und ja, nach Durchsicht der passwd stelle ich fest, dass der User iobroker angelegt worden ist, er wohl aber nicht zur Nutzung einer Shell vorgesehen ist:

iobroker:x:1000:1000::/home/iobroker:/usr/sbin/nologin

[Wildbill]

@ch90045 Exakt dieses. Aber alle Befehle, die mit iobroker beginnen werden eben im Kontext von iobroker ausgeführt. Was eben zu Problemen führt, wenn dann gewisse Dateien oder Ordner root gehören, weil man unter root und nicht mit einem normalen Benutzer installiert hat. Ist so unter Linux, war immer so und wird wohl immer so sein. Deshalb solltest Du einfach einen normalen Benutzer anlegen, diesem sudo erlauben, ihn in die Gruppe iobroker bringen und einmal "iobroker fix" ausführen. Dann ist Dein System (hoffentlich) in einem Zustand, bei dem man gezielt helfen kann und keine anderweitigen Probleme mehr zu erwarten sind.
Vielleicht noch ein Beispiel: Ich kaufe mir eine supertolle Software (oder lade Freeware), die es nur für Windows gibt. Ich habe keinen Windows-Rechner, denke aber, ich kenne mich ja aus, und installiere das in Linux mittels Wine. Nun funktioniert es doch nicht (wie erhofft). Dann kann ich doch auch nicht den Hersteller um Support bitten. Der wird mir auch sagen, installiere es, wie es vorgesehen ist (direkt unter Windows XY) und wenn es dann Probleme gibt, dann melde Dich und wir sehen weiter. Exakt gleich ist es eben hier.
Ich weiss nicht, warum Du Dich so streubst, einfach mit einem normalen User zu arbeiten.
Falls wir hier nicht mehr zueinander finden, wünsche ich Dir auch eine ruhige und besinnliche Weihnachtszeit und dass Du vielleicht jemand findest, der Dir dennoch bei Deinem ursprünglichen Problem helfen kann und will. Wobei ich immer noch nicht ausschließen möchte, dass es eben genau daran und möglichen fehlenden Rechten liegen könnte.
Da stecke ich aber nicht tief genug im iobroker-Development, um das sicher bestätigen oder ausschließen zu können.

Gruss, Jürgen

[Asgothian]

-- was hier stand wurde gelöscht - anscheinend gibt es bereits eine Lösung --

[ch90045]

@homoran Erledigt (heute um 10:55) - läuft nun unter einem "normalen" user. Das "Boiler Skript" lief heute um 6:00 ohne Probleme und es gab einen Eintrag.

Danke!

[ch90045]

@asgothian Ich brauch (leider) keinen Wecker - ich mache das morgen mal - ob das gelöst ist, weiss ich ja noch nicht. Ich hatte auch schon nach deConz logs gesucht, bin aber bei github auf folgendes gestossen:

"deCONZ doesn't write log files to not pollute the sd-cards in long running setups."

Ich bin halt gespannt, ob das wieder auftaucht und überlege ob ich mir für kurz nach 6:00 ein Check schreibe, der mir meldet, ob wirklich geschaltet wurde.

Ich bin mir unsicher, ob der reboot wirklich notwendig war, auch habe ich ja nun zwei Blockly Skripte wo vorher 2 waren.

Wie gesagt, ich habe mal ein Auge drauf und würde mich noch mal melden.

Danke

[paul53]

@ch90045 sagte: unsicher, ob der reboot wirklich notwendig war

Der Neustart von ioBroker (Node.js) hat aufgeräumt.

[ch90045]

@paul53 Hallo Paul, dann bin ich erst recht skeptisch, ich hatte Ende letzter Woche iob neu gestartet.

[Homoran]

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

den Nutzer iobroker gibt es nunmal hier nicht

dann läuft bei dir auch kein iobroker.
Dieser Nutzer wird intern bei der Installation von iobroker angelegt.