Scripte laufen nicht mehr seit Update auf JS-Controler 3.0x
-
@AxelF1977 Das dürfen aber alles Fehler in den einzelnen skripten sein.
-
@Thomas-Braun sagte in Scripte laufen nicht mehr seit Update auf JS-Controler 3.0x:
@AxelF1977 Das dürfen aber alles Fehler in den einzelnen skripten sein.
Ok, ich wollte es nur teilen, evtl. wäre was dabei gewesen
-
@AxelF1977 Das Modul 'axios' für den Staubsauger wird nicht gefunden, das kann ich dem noch entnehmen. Sonst eigentlich nur JS-Zeug. Hab ich keinen Plan von.
-
@Thomas-Braun sagte in Scripte laufen nicht mehr seit Update auf JS-Controler 3.0x:
@AxelF1977 Das Modul 'axios' für den Staubsauger wird nicht gefunden, das kann ich dem noch entnehmen. Sonst eigentlich nur JS-Zeug. Hab ich keinen Plan von.
Ich habe jetzt das Rollback auf den js-controller 2.2.10 ausgeführt
gordon@ioBrokerPC:~$ cd /opt/iobroker gordon@ioBrokerPC:/opt/iobroker$ iobroker stop gordon@ioBrokerPC:/opt/iobroker$ npm i iobroker.js-controller@2.2.10 --production [sudo] Passwort für gordon: > iobroker.js-controller@2.2.10 preinstall /opt/iobroker/node_modules/iobroker.js-controller > node lib/preinstallCheck.js NPM version: 6.14.4 > iobroker.js-controller@2.2.10 install /opt/iobroker/node_modules/iobroker.js-controller > node iobroker.js setup first The following notifications happened during sync: - Ignoring Directory "mqtt.admin" because officially not created as meta object. Please remove directory! - Ignoring Directory "tr-064-community.admin" because officially not created as meta object. Please remove directory! - Ignoring Directory "tuya.admin" because officially not created as meta object. Please remove directory! npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@~2.1.2 (node_modules/chokidar/node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@^1.0.5 (node_modules/iobroker.info/node_modules/osx-temperature-sensor): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.5: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) npm WARN babel-eslint@10.1.0 requires a peer of eslint@>= 4.12.1 but none is installed. You must install peer dependencies yourself. + iobroker.js-controller@2.2.10 removed 252 packages and updated 4 packages in 14.607s 17 packages are looking for funding run `npm fund` for details gordon@ioBrokerPC:/opt/iobroker$ iobroker startJetzt geht wieder alles wie es war.
-
@AxelF1977
Prima. Dann hast du dein System ja wieder sauber. -
@Thomas-Braun
Na ob das so prima ist, wenn es mit dem aktuellen JS-Controller nicht läuft? Da ist doch was faul, da er der einzige ist, bei dem Scripte mit 3.* nicht laufen -
@Thomas-Braun sagte in Scripte laufen nicht mehr seit Update auf JS-Controler 3.0x:
@AxelF1977
Prima. Dann hast du dein System ja wieder sauber.Auf jeden Fall sauberer als vorher! Und dafür danke ich Dir sehr. Vor allem für Deine Geduld.
@Jan1 sagte in Scripte laufen nicht mehr seit Update auf JS-Controler 3.0x:
@Thomas-Braun
Na ob das so prima ist, wenn es mit dem aktuellen JS-Controller nicht läuft? Da ist doch was faul, da er der einzige ist, bei dem Scripte mit 3.* nicht laufenNur was könnte es sein. Da es jetzt aber läuft, belasse ich es wie es ist. Vielleicht hat ja jemand die Tage mal die Muße und eine Idee.
-
@Jan1 said in Scripte laufen nicht mehr seit Update auf JS-Controler 3.0x:
Na ob das so prima ist, wenn es mit dem aktuellen JS-Controller nicht läuft? Da ist doch was faul, da er der einzige ist, bei dem Scripte mit 3.* nicht laufen
Da 2.2.10 (oder 2.2.9?) die aktuelle Version in default ist... Kann man machen, imho.
-
@AxelF1977
Mit nem Backup hattest es ja schon versucht, wobei wie hast das gemacht?
Ich bin ja ein Fan des Backitup Adapter und wenn ich damit ein Backup einspiele, dann gehe ich immer so vor:-
IOBroker Ordner löschen
-
IObroker installieren
-
auf latest umstellen (kann natürlich auch auf default bleiben, nur wenn man schon mal dabei ist)
-
alle Updates durchführen
-
Backitup Adapter installieren
-
Backup über den Adapter wieder herstellen
-
alle Updates (falls vorhanden) durchführen
So klappt das bei mir immer und das System ist danach aktuell und wirklich sauber.
-
-
@Thomas-Braun sagte in Scripte laufen nicht mehr seit Update auf JS-Controler 3.0x:
@AxelF1977 Da meldest du dich nicht als root an!
Ein Debian immer per 'sudo' managen.Iobroker wurde zu Beginn als „Root“ installiert wenn ich mich richtig zurück erinnere.
Außerdem kann man ruhig Root verwenden wenn man weiß was man macht.
Meine iobroker hauptinstallation stammt auch noch aus der Zeit und die manage ich schon ewig völlig problemlos als Root.
Aber zu dem JS Problemen habe ich am Handy im log was mit „Logs „ gesehen.
Da hat sich wenn ich das noch finde etwas geändert und musste auch in einige Adapter implementiert werden was das Schreiben in das log betrifft.
Glaube das ist in deinen scripten das Problem.
Ich suche mal.
-
@wendy2702 said in Scripte laufen nicht mehr seit Update auf JS-Controler 3.0x:
Außerdem kann man ruhig Root verwenden wenn man weiß was man macht.
Außerdem kann man ruhig Root verwenden wenn man weiß was man macht.
Das ist aber genau der Punkt: Die meisten springen in den root rein und fuhrwerken eben ohne zu wissen was die da so treiben auf dem System rum. Je weiter man sich vom vorgesehenen Standard entfernt, umso mehr muss man sein System kennen.
-
@Thomas-Braun
Na wenn ich ich alles mit sudo unterm normalen User mache, kann ich zu 95% mein System genau so ruinieren, wenn ich gar nicht weiß was ich mache.
Könntest mal ein konkretes Beispiel dafür geben was ein 08/15 User mit root schießt was er mit "normalem User und sudo nicht schießen würde?
Klar ist und da hast vollkommen Recht, es ist nicht gedacht immer mit root angemeldet zu sein. -
Mal gesehen das schon auf zwei Fehler im Script hingewiesen wurde.
Ist das mal untersucht worden oder besteht nach dem downgrade überhaupt noch Interesse?
-
@Jan1
Klar, mit einem 'sudo rm -rf /' schaufelst du dir genauso ein Grab wie mit dem gleichen Befehl als root.
Aber wenn du als root unterwegs bist läuft das (u. U.) in einem anderem userenvironment ab. Mit 'sudo' läuft das zwar mit root-Rechten ab, allerdings im userspace. Das macht schon einen Unterschied.
Deswegen werden ja z. B. auch einige Systembefehle (wie z. B. 'ping') auch mit setuserid angelegt:pi@raspberrypi:/opt/iobroker $ ls -la /bin/ping -rwsr-xr-x 1 root root 55720 Aug 3 2018 /bin/pingWarnhinweis: Die o.a. Befehle sollten nicht eingegeben werden, auch nicht testweise!
-
@Thomas-Braun
Für Dich vielleicht, für mich hört sich das schon wieder nur nach Bahnhof an und wer kommt schon auf die Idee sich sein root Verzeichnis löschen zu wollen? Ein User der nicht viele Plan hat, der kennt solche Befehle gar nicht und macht in der Regel eh fast alles mit copy & paste was er hier im Forum so liest. -
@Jan1 @Thomas-Braun @wendy2702
Ich mag ja dieses T-SHirt ...
[Nachtrag]
na gut, dann sicherheitshalber einen Hinweis:
Liebe Kinder, macht das NIEMALS ansonsten könnte es sein, dass ihr beim Aufruf eines ansich harmlosen Befehles alle Dateien und Verzeichnisse von eurem Linux System löscht!! -
@BBTown Mach das weg! Das ist böse!
-
@Thomas-Braun
aber erklärt wie ein DAU auf sone blöde Idee kommen kann
-
Die Diskussion über die Verwendung des ersten Users als 'sudoer' und inaktivem root gab es intensiv mit Aufkommen der ersten Version von ubuntu. Die haben das soweit ich weiß als erste umfassend so gemacht. Mittlerweile macht Debian (von dem ubuntu ja abstammt) das aber aus guten Gründen auch so. Das ganze ist aber Debian-typisch heiß diskutiert worden.
-
@Thomas-Braun
Ja aber diese Gründe erschließen sich einem Linux Laien aber eben nicht, wenn nur in dem ständig darauf hingewiesen wird ohne dass mal ein Beispiel kommt, bei dem der Groschen fällt. Egal, wird eh gerade zu OT das ganze, wobei mich es wirklich an einem einfachen Beispiel erklärt interessieren würde, wo es für den normalen User gefährlicher wird.
