UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[apollon77]

@msauer Ok, ds sieht an sich alles ok aus ... keine ahnung warum npm her die pakete wegwirft

[msauer]

@apollon77 Es funktioniert ja auch alles danach. Auch Reboots funktionieren fehlerfrei..Sobald ich aber einen Adapter installiere/update kommen die Fehler.

Danach ist dann aber auch alles weitere nicht mehr möglich.

[Kueppert]

Ich habe gerade testweise nach dem Wechsel auf jsonl auch meinen HM-RPC-Adapter upgedated. Alles problemlos verlaufen.
Hatte vorher auch redis und file und nun beides auf jsonl...

[msauer]

@apollon77 sagte in [EXPERIMENTELL: keine ahnung warum npm her die pakete wegwirft

Könnte es an NPM Version 7.5.4 liegen? Sind vielleicht nicht alle notwendigen Dependencies installiert worden?

[crunchip]

@msauer ich lese hier, du hast node14 und npm 7.5 das ist wahrscheinlich dein Problem

[msauer]

@crunchip ja, das denke ich auch...mit redis/file funktioniert die Version, mit jsonl nicht, da wohl einige Abhängigkeiten nicht mit installiert werden. Sollte also Oben als Hinweis vermerkt werden, bloß nicht npm 7 zu nehmen...oder die Abhängigkeiten anzupassen.

[msauer]

@crunchip ich habe mal versucht auf npm 6.14.11 zurück zu gehen. Da bekomme ich dann npm Fehler bei der Installation von Adaptern...ich denke ich gehe wieder auf meinen Snapshot zurück und warte, das dies alles mit npm 7 auch funktioniert..schade eigentlich, aber ja meine Schuld..bin halt manchmal etwas zu uptodate.

[crunchip]

@msauer soviel ich weiss, sollte aktuell npm7.x noch gar nicht genommen werden und alle Adapter sollten mit 6.x funktionieren.

[apollon77]

@msauer ich sage es mal so: npm 7 steht in den js-controller 3.2 Infos als grosses "DO NOT USE IT" drin ... also ehrlich: schau wie Du auf npm 6 zurückkommst.

Wir haben zwar inzwischen den iobroekr installer mit npm7 im Griff, aber es sind jetzt zwei Themen bereiche bekannt wo es "spinnt":

• github installs verhalten sich teilweise komisch
• und das issue hier das er scheinbar denkt das pakete unused sind und wegräumt ...

[crunchip]

@msauer sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

Da bekomme ich dann npm Fehler bei der Installation von Adaptern.

Die da wären?

[apollon77]

@msauer EIne Idee haben wir noch, Installiere die json pakete mal in /opt/iobroker (also nicht wie oben angegeben im /opt/ioborker/node_modules ...). Schau mal ob er es dann "behält".

Vllt will ja npm7 wieder anders behandelt werden.

[Thomas Braun]

@apollon77 @msauer

root@MSNUC-IOB:/opt/iobroker/node_modules/iobroker.js-controller# npm i @iobroker/db-states-jsonl @iobroker/db-objects-jsonl

Als root macht man das halt auch nicht.
Zusätzlich zum npm@7.

[apollon77]

@thomas-braun Auch wahr ... oder danach "Iobroker fix" aufrufen :-)

[Thomas Braun]

@apollon77
Ich bin an der Stelle ja Verfechter davon gleich sauber mit dem System umzugehen und nicht den ganzen Mist nachträglich per fixer geradeziehen zu müssen.
root-shell ist TABU!
(Außer auf Dockern/Synology. Da geht's ja wohl nicht anders.)

[Kueppert]

hm, ich lese immer wieder, man soll das nicht als root machen...ich mache alles, seit ich Linux nutze, als root (mein, ich hab hier 2016 oder 2017 gestartet). Bei mir war es nämlich genau anders herum: immer wenn ich mit Usern gearbeitet habe, hatte ich Rechte-Probleme, mit root natürlich nie, der darf ja allet.
Inwiefern macht es denn (für mich jetzt zB) Sinn, auf nen User zu schwenken, wenn man die gesamte Heimautomatisierung im Heimnetz betreibt und nur via VPN Zugriff auf diese hat? Ist ne ehrlich gemeinte Frage :)

[Thomas Braun]

@Kueppert

Dann machst du es seit 2016 oder 2017 falsch.
Bzw. hast das Konzept der Trennung in den user space nicht kapiert.
Wenn dir das System sagt, das darf $USER xyz nicht, dann hat das schon seine Gründe.
Das Setup des ioBrokers basiert darauf, dass es einen user iobroker gibt, der sehr fein abgestimmt gewisse Dinge tun darf oder auch nicht. Gleiches gilt für den Standarduser. Der darf auch nur soviel im System wie notwendig.
root wird garnicht vollständig aktiv sondern die Rechte des root werden nur Fallweise per sudo vom Standarduser übernommen.

Wenn du jetzt das Konzept über den Haufen wirfst reagiert das feinabgestimme Konstrukt anders als vorgesehen.

Ich kenne auch noch andere Zeiten, in denen beim klassischen Installations-Dreisatz aktiv die Rolle gewechselt werden musste und man in einer root-shell aktiv war. Gut das die Zeiten bei den meisten Distributionen vorbei sind. ('Linux' im Einsatz seit 2001 oder so).

Das ganze ist ja kein Designfehler von irgendwem, sondern grundlegend für den Umgang mit dem System. Nicht ohne Grund hat Linux den Ruf stabiler als andere Systeme zu sein. Warum? Weil eben nicht 'Hinz und Kunz' alles drauf werfen darf.
Bei Windows gibt es ja wohl mittlerweile was ähnliches.

[JLeg]

@thomas-braun sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

Das Setup des ioBrokers basiert darauf, dass es einen user iobroker gibt, der sehr fein abgestimmt gewisse Dinge tun darf oder auch nicht.

echt jetzt? "best practice" in allen Ehren, aber was wäre denn beim User iobroker "sehr fein abgestimmt", ausser dass sein Homedir bzw. Standarddir ihm gehört? Ich wüsste nicht, dass ACLs, apparmor- oder selinux-Templates in Gebrauch wären - oder Ähnliches... (?)

[Thomas Braun]

@jleg
Schau in die sudoers.
ACLs sind auch aktiv.

[JLeg]

@thomas-braun sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

@jleg
Schau in die sudoers.

Jo, damit werden Einschränkungen selektiv aufgehoben - wird aber durch "root"-Nutzung nicht unmittelbar "zerstört"...

ACLs sind auch aktiv.

bei mir offenbar nicht - klar sind ACLs "aktiv", ich zumindest sehe da aber nur das Standardmapping...

[Thomas Braun]

@jleg
Wenn man weiß was man tut...
Nur die meisten 'Ich bin root, weil ich das System nur so handeln kann'-User wissen es ja eben NICHT.
Und die Kombination 'relative Ahnungslosigkeit' und 'Ungefilterter Vollzugriff auf alles' ist halt denkbar ungünstig.

Die Tage war auch irgendein User hier unterwegs, mit gleich dreifacher Installation von node. Eine in /root, eine in /usr/local/bin und dann eine saubere. Halleluja, das funktioniert alles prima.

Ich bin z. B. auf meinem System noch nie in eine root-shell gewechselt. Wozu auch? Ich hab aber schon im falschen Verzeichnis einen falschen Befehl eingegeben. Als root wäre der durchgeschossen, als Standarduser ist nix passiert.