Neuer Installer und neuer Fixer: übersichtliche Oberfläche und `iob docker`

[Thomas Braun]

@crunchip sagte:

dmesg: read kernel buffer failed: Operation not permitted

Bei Containern normal, du kannst da nicht auf den Host durchgreifen.

@peter-v.
Bring die 3 github-Installationen ins Trockene. installier die also ordentlich über ein Repository.

[crunchip]

@Thomas-Braun sagte:

Bei Containern normal, du kannst da nicht auf den Host durchgreifen.

der container hat doch den Kernel vom Host

[Thomas Braun]

@crunchip sagte:

der container hat doch den Kernel vom Host

Ja, aber du kannst nicht per 'dmesg' auf den Kernelringpuffer des Hosts zugreifen. Dann würdest du ja aus dem Container ausbrechen. Das will ja keiner.

[Peter V.]

Habe mal die Scripts installiert, allerdings sind da ein paar ältere Versionen mit gelistet, Beispiel:
@serialport/bindings-cpp@13.0.0 / 12.0.1 -> installiert ist jetzt 13.0.1
@stoprocent/bluetooth-hci-socket@1.5.2 -> installiert ist jetzt 2.3.0
@stoprocent/noble@1.19.1 -> installiert ist jetzt 2.8.0
protobufjs@6.11.6 -> installiert ist jetzt 7.6.5

Kann man die anderen löschen? Oder sind die nötig?

[Thomas Braun]

@Peter-V. sagte:

Kann man die anderen löschen? Oder sind die nötig?

Nix löschen, nur freigeben.

Was meinst mit

Habe mal die Scripts installiert

[Peter V.]

npm install-scripts approve xxxxx

sorry, hab mich wohl falsch ausgedrückt.

Wie kann ich sie freigeben?

[Thomas Braun]

@Peter-V.

Ich weiß immer noch nicht, was du genau mit

Habe mal die Scripts installiert

meinst. Du sollst da nix installieren.

[mcm1957]

Mit node 24 / npm 11 wird NICHTS geblockt. Da brauchst auch nix freizugeben.
Das sind alles nur npm WARNINGs und die notwendigen Freigaben werden vor node 27 (da wird das Ganze mit npm 12 dann scharf) geeignet erfolgen.

Die Warnings können derzeit einfach ignoriert werden. Und einfach mal alles Scripts ohne Abklärung freizugeben schaltet den sinnvollen zufünftigen nmp Sicherheitsmechanismus aus. Die letzten npm security Vorfälle basierten oft auf eingeschleusten scripts.

[Thomas Braun]

@mcm1957

Kann man das dann als Maintainer des Pakets mitgeben? Ich meine ich hätte da sowas gelesen.

[mcm1957]

oder anders gesagt - sorry wenn ich Thomas widerspreche -

USERn wird von der Verwendung von 'npm install-scripts approve <pkg>' o.ä. dringen ABGERATEN.

Allfällige Anpassungen müssen und werden in den jeweiligen Adaptern vorgenommen. Derzeit wird nichts geblcokt.

[Thomas Braun]

@mcm1957 sagte:

sorry wenn ich Thomas widerspreche -

Nö, ist kein Widerspruch. Hatte doch oben schon ergänzt:

Edit: Soweit ich das verstanden habe wird das aber erst mit npm12 'scharf geschaltet', bei npm 11 ist es zur Zeit nur eine Anzeige und dient zum testen.

[Peter V.]

Danke für eure Infos und Hilfe.
Auch wenn ich jetzt einige Scripte mit "npm install-scripts approve" bearbeitet habe, hoffe ich doch, das jetzt am System nix verbogen ist.
Ansonsten läuft mein Setup ganz zuverlässig.
Die Git installationen sind bis auf einen Adapter (FritzDect) gerade gezogen. Bei dem warte ich jetzt noch, da dort einige spezielle Anpassungen drin sind.
Nochmals Danke ;)

[Thomas Braun]

@Peter-V. sagte:

Auch wenn ich jetzt einige Scripte mit "npm install-scripts approve" bearbeitet habe, hoffe ich doch, das jetzt am System nix verbogen ist.

Da die Meldungen eh zur Zeit für npm 11 ohne Relevanz sind ist da auch nix verbogen. Bis npm12 werden die Pakete vermutlich ohnehin nochmal aktualisiert und fallen wieder in den Sperrzustand zurück.

[Krisiun]

Alles hat super geklappt 👍
Vielen Dank 😊

[Krisiun]

Ich muss mein Kommentar etwas korrigieren ,

Bei mir lief Node.js 24.21.0 grundsätzlich stabil, allerdings ist der RAM-Verbrauch des ioBroker/js-controller deutlich angestiegen. Unter Node 24 lag der Prozess zeitweise bei ca. 1–2 GB RSS. Nach dem Wechsel zurück auf Node 22.23.3 liegt er wieder bei rund 400 MB RSS. Funktionale Probleme hatte ich dabei keine, auffällig war vor allem der deutlich höhere Speicherverbrauch.

[Samson71]

@Krisiun
Das ist nichts neues

https://forum.iobroker.net/topic/85471/steigender-ram-swap-nach-update-auf-nodesjs24

[Krisiun]

@samson71
Sorry wusste ich nicht

[Thomas Braun]

@Krisiun sagte:

auffällig war vor allem der deutlich höhere Speicherverbrauch.

Was aber grundsätzlich kein Fehler oder Problem ist. Hängt halt von der Grundausstattung des Systems ab und wie z. B. dein swap konfiguriert ist.

[bennohaf]

Vielen Dank @tombox . Auch wenn ich keinen Linux Hintergrund habe, habe die v24 ohne Probleme dank deiner Vorgehensweise installiert. Auch merke ich noch keine Performance Probleme mit meinem PI 4 8GB. Danke!

[Krisiun]

@thomas-braun
Danke für die Erklärung. Performance-Probleme hatte ich unter Node 24 ebenfalls nicht. Mein Pi 5 hat 16 GB RAM, Swap wurde nicht benutzt und es waren noch rund 11 GB verfügbar. Auffällig war für mich nur der Unterschied beim js-controller: Unter Node 24.21.0 lag der RSS zeitweise bei ca. 2 GB, nach dem Wechsel zurück auf Node 22.23.3 nach rund 24 Stunden bei ca. 400 MB. Ist so ein Unterschied zwischen Node 22 und 24 aus deiner Sicht noch normal bzw. durch das geänderte Speichermanagement erklärbar?