Update Node-js V4.x auf V6.x

apollon77

~~@fsjoke:~~

Ich versuche nur code zu schreiben die auf 4 (4.7.2 momentane Version) läuft. Es ist verlockend und man gewöhnt sich zu schnell an Dinge die bei 6 anstandslos funktionieren (Beispiel: Klassen, rest-parameter …x, parameter mit default-Werten) aber ich denke dass man nicht alle zwingen soll auf 6 zu gehen. `

Sehe ich auch so

Neue Adapter können in meinen Augen problemlos ab 4.x funktionieren. Bestehende Adapter müssen schon einen seeeeehr guten Grund haben die Abwärtskompatibilität zu brechen.

Ich denke ein Adapter zu haben der nur unter 6.x läuft bedeutet das Ihn aktuell fast niemand nutzen kann/nutzt, damit istdie Frage ob der ENtwickler damit zufrieden ist :) Ich glaube es ist noch zu früh.

https://github.com/nodejs/LTS

Also danach ist node 4.x bis April 2017 noch im "kriegt regelmäßige Updates"-Modus und dann bis April 2018 noch im Maintenance (=Bugfixing) Support.

Die 0.xer Versionen sind auch schon aus dem Bugfix-Support raus … also hier kann das Ziel nur sein: Upgrade!!! (leider meistens inklusive OS drunter)

Ich denke ab April sollten wir die 6.x als "Empfehlung" setzen und die 4.x als "geht auch noch für mind 1 Jahr) :-)

Ingo F

Homoran

~~@apollon77:~~

Ich denke ab April sollten wir die 6.x als "Empfehlung" setzen und die 4.x als "geht auch noch für mind 1 Jahr) :-) `
ich werde weiter mit 6.x testen und auch schon Images erstellen (das aktuelle BPi Image ist mit nodejs 6.x!)

Kannst du mal sagen, bei welchen Adaptern es deiner Meinung nach zu Problemen kommen könnte?

Gruß

Rainer

Jeeper.at

Hallo,

ein Step by Step wäre nicht schlecht.

ich bin noch auf 4.x, würde aber zwecks Zukunftsicherheit gerne auf 6.x umsteigen.

Da das aber mein Produktivsystem ist will ich vorher die Risiken abklären.

Lg

Günther

Homoran

~~@Jeeper.at:~~

ein Step by Step wäre nicht schlecht. `
sieh mal in die ersten Posts dieses Threads

Gruß

Rainer

Jeeper.at

Ok, ich präzisiere. :-)

Ein Step by Step für Windows Installationen.

Lg

Günther

apollon77

~~@Homoran:~~

~~@Jeeper.at:~~

ein Step by Step wäre nicht schlecht. sieh mal in die ersten Posts dieses Threads

… es fehlt aber genau "Pakete neu installieren" Schritt :-(

Blackmike

Hmm, das wüsste ich dann auch gerne, ob und was dann neu installiert werden müsste.

Ich denke mal, zumindest für die offiziellen Adapter müsste die Aussage zu treffen sein, geht oder benötigen manuellen Eingriff.

An der Möglichkeit eines bash-scriptes für Upgrade 4.x.x auf 6.x.x wäre ich dann auch interessiert.

apollon77

Ich würde einfach (sicherheitshalber) alle Module reinstallieren … dann ist es sicher und man muss es nicht von der Liste der Adapter abhängig machen.

Laut Bluefox reicht das hier aus:

https://github.com/ioBroker/ioBroker.js ... install.sh

Müsste an sich in jeder Installation irgendwo sein ... müsste man mal testen :-) Und dann ne Windows-Version bauen :-)

Jeeper.at

Interessant in dem Zusammenhang wäre für mich, wenn ich die Adapter neu installiere ob dann die Einstellungen weg sind?

Lg

Günther

apollon77

Ne, das installiert nur "den Code" neu (so als wenn er ein Adapter-Update installieren würde nur das er halt die gleiche version drüberinstalliert) … Alle Werte und Einstellungen bleiben da unangetastet

olifre

~~@apollon77:~~

Laut Bluefox reicht das hier aus:

https://github.com/ioBroker/ioBroker.js … install.sh

Müsste an sich in jeder Installation irgendwo sein ... müsste man mal testen :-) Und dann ne Windows-Version bauen :-) `

Danke für den Tipp…

an sich eine gute Idee, bei mir ist nur die re-Installation eines Adapters fehlgeschlagen. Da das Script keinerlei Fehlerbehandlung macht, stand das System dann am Ende in "/" und hat dort

chmod 777 * -R

ausgeführt, rekursiv auf alle Dateien im gesamten Dateisystem.

Super Idee, jetzt darf ich mein Raspbian neu aufsetzen…

Ich hab' meine Lektion gelernt: Nicht blind das Skript ausführen, sondern in Zukunft lieber per Hand die Adapter reinstallieren.

apollon77

Uuups … dann muss man da wohl nochmal ran :-(

Homoran

Das liegt IMHO daran, dass dieses skript als reinstall.sh im Ordner/ opt/iobroker liegt. Wenn es da ausgeführt wird geht das -R nur innerhalb von iobroker.

Gruß

Rainer

apollon77

ne nicht ganz.

wenn in dem Skript ein "npm install" fehlschlägt und damit auch das Verzeichnis "node_modules" nicht existiert dann schlägt das "cd node_modules" fehl. Damit bleibt man im gleichen verzeichnis. Dann macht das Skript aber ein "cd .." … und das macht dann gaaaanz dumme dinge

olifre

~~@Homoran:~~

Das liegt IMHO daran, dass dieses skript als reinstall.sh im Ordner/ opt/iobroker liegt. Wenn es da ausgeführt wird geht das -R nur innerhalb von iobroker. `
Genau da liegt es bei mir. Und da habe ich es auch ausgeführt.

Im Skript steht:

while read in; do npm install $in --production; cd node_modules/$in/; npm install --production; cd ../..; done < list.txt

Der Haken: Wennnpm install $in --productionfür einen Adapter fehlschlägt, wird der Unterordner````
node_modules/$in/


Daraufhin klappt das````
cd node_modules/$in/
````nicht, das````
npm install --production;
````tut nichts, und das````
cd ../..
````, das ja dennoch ausgeführt wird,

wechselt in den toplevel, also````
/
````.

Die Schleife läuft munter weiter. Weitere Adapter werden also jetzt statt in````
/opt/iobroker/node_modules
````lustig in````
/node_modules
````installiert.

Und zu guter Letzt läuft dann````
chmod 777 * -R
````auf das ganze Dateisystem.

Habe mein System erstmal kurz repariert, indem ich die ssh-Host-Keys mit ordenlichen Permissions versehen habe, und reinstalliere jetzt alles.

Meiner Meinung nach sollte:

while read in; do npm install $in --production && cd node_modules/$in/ && npm install --production && cd ../..; done < list.txt

gehen, dann wird das jeweils nächste Kommando nur dann ausgeführt, wenn das davor geklappt hat.

Das kann natürlich immer noch schief gehen, wenn das````
npm install --production
````fehlschlägt. Ein ordentlicheres Error-Handling evtl. mit trap, oder mit pushd / popd wäre sicher besser, wenn jemand Zeit und Lust hat, das mal zu reparieren…

Oder sich vorher PWD merken und immer dahin zurückgehen, statt "cd ../.." zu benutzen.

Mein Problem war übrigens, dass sich der Adapter "iobroker.js-controller" nicht installieren ließ, gleiches Problem wie hier:

[http://forum.iobroker.net/viewtopic.php?t=3345](http://forum.iobroker.net/viewtopic.php?t=3345)

Abhilfe hätte ein:

cd /opt/iobroker
sudo chmod 777 * -R

****vorher**** gebracht. Das sollte man also auch ins Skript vorher einbauen, zusätzlich zum "nachher".

frankjoke

Ich habe das original-script für Linux etwas abgeändert:

Zuerst gehe ich natürlich ins /opt/iobroker oder wo ihr das sonst habt

Dann erzeuge ich mit````
ls -1 ./node_modules | grep iobroker. > list.txt

eine Liste der Adapter. Kann sie dann noch bearbeiten um etwaige Adapter die ich nur für tests drinnen hatte wieder zu entfernen.

Dann starte ich das script mit:

sudo iobroker stop
sudo rm node_modules/* -R
sudo rm iobroker
sudo npm install iobroker --unsafe-perm
chmod 777 * -R
while read in; do npm install $in --production ; done < list.txt
chmod 777 * -R
iobroker upload all
sudo iobroker start


Vielleicht ist ein chmod überfällig aber sonst hat es bis jetzt funktioniert. Leider werden die original npm-versionen geladen aber man kann ja list.txt ändern um sie durch git-versionen zu ersetzten.

Wenn ein adapter mucken macht dann versuch ich ihn mit sudo npm nachzuinstallieren aber sonst installiere ich nur iobroker selbst als sudo.

In Windows mach ich im Prinzip das selbe aber ohne sudo und und chmod, habe mir 'ne Liste mit adapter-npm-commandos (npm install adapter xxxx –production) angelegt anstatt die list.txt zu erzeugen.

apollon77

~~@olifre:~~

Meiner Meinung nach sollte: `

Super Ideen. Vor allem auch anstelle dem "cd .." kram direkt den Pfad zu merken, das chmod am Anfang ist auch sinnvoll.

Wenn Du magst pass es an und liefere es als Pull-Request ein oder schreib es im Forum, dann übernehme ich es.

Ich würde Sonntag da nochmal reinschauen (bin jetzt 2 Tage unterwegs) oder Bluefox ist schneller. :-)

Ingo F

aquapro

EDIT sagt: Frage nicht mehr relevant.

Gruß

Tino

Fitti

Jaja, die immer und überall geführten Diskussionen… 8-)
~~@apollon77:~~

Ich denke ein Adapter zu haben der nur unter 6.x läuft bedeutet das Ihn aktuell fast niemand nutzen kann/nutzt, damit istdie Frage ob der ENtwickler damit zufrieden ist :) Ich glaube es ist noch zu früh. `
Das sehe ich genauso.
~~@apollon77:~~

Also danach ist node 4.x bis April 2017 noch im "kriegt regelmäßige Updates"-Modus und dann bis April 2018 noch im Maintenance (=Bugfixing) Support. `
Und selbst danach… viele nutzen überhaupt nicht die aktuellsten Patche, da auch überhaupt nicht notwendig. Wer sein System frei macht ist selber schuld. Mein ioBroker läuft stark abgeschirmt.
~~@apollon77:~~

Ich denke ab April sollten wir die 6.x als "Empfehlung" setzen und die 4.x als "geht auch noch für mind 1 Jahr) :-) `
Macht mir natürlich sorgen. Mein ioBroker will einfach nicht vernünftig auf einem Raspi, Banana oder Cubi laufen. Wahrscheinlich zu viel drauf. Vor allem Speichernutzung und CPU Takt sind Primärprobleme. Aber auch schlechte Images von Herstellern.

I. d. Tat habe ich noch nie eine solch problemlose Installation wie auf der Synolgie gehabt. Hier bin ich aber eingeschränkter in den Versionen.

Und dennoch laufen große Videokonverter, CMS-Systeme, Datenbanken usw.. Und ein ioBroker Adapter, der zumeist nur einfache Aufgaben erledigt, benötigt nun das allerneueste?

Aus wirtschaftlichen Gründen ist es auch ideal,da diese die ganze Zeit läuft.

Ich bitte es nochmal wirklich zu durchdenken, ob nun der eine neue gute Befehl, der mit 10 weiteren Codezeilen auch so erledigt werden kann, das rechtfertigt. Es steigt auch nicht jeder gleich auf Windows 10 um.

Oft ist es doch nur die Detailverliebtheit von Programmierern und nicht die technische Notwendigkeit. Das kenne ich aus vielen beruflichen Situationen genauso. Admins und Entwicklung streiten oft über die Ansichten.

Letztendlich verliert immer nur der User/Kunde.

Ich wollte einfach mal eine andere Sichtweise aufbringen.

Fitti

apollon77

~~@Fitti:~~

~~@apollon77:~~

Ich denke ab April sollten wir die 6.x als "Empfehlung" setzen und die 4.x als "geht auch noch für mind 1 Jahr) :-) `
Macht mir natürlich sorgen.

…

Ich bitte es nochmal wirklich zu durchdenken, ob nun der eine neue gute Befehl, der mit 10 weiteren Codezeilen auch so erledigt werden kann, das rechtfertigt. Es steigt auch nicht jeder gleich auf Windows 10 um.

Oft ist es doch nur die Detailverliebtheit von Programmierern und nicht die technische Notwendigkeit. Das kenne ich aus vielen beruflichen Situationen genauso. Admins und Entwicklung streiten oft über die Ansichten.

Letztendlich verliert immer nur der User/Kunde. `

Valide Sichtweise und ich kann Dir versichern das denke keiner der Entwickler absichtlich Nutzer aussperren wird - vor allem nicht für bestehende Funktionen. Auch wenn die "Empfehlung für neue Installation" (so bezeichne ich es mal) höher ist ändert sich nicht so viel.

Man muss aber auch sagen das halt node 0.x im Speichermanagement einige Probleme hatte, es mit 4.x besser ist und 6.x nochmal besser sein soll.

Als Entwickler im nodejs-Umfeld muss man aber auch die Abhängigkeiten berücksichtigen. Man baut nicht alles selbst sondern nutzt Libraries. Wenn man also Funktionen nicht selbst bauen will und eine Library findet kann es sein das diese schon eine node-Limitierung vorgibt. Ich baue gerade einen Adapter um Smartmeter per SML auszulesen und da gibt es eine Library die ich nutzen kann für das Protokoll. Diese ist aber erst ab node 4.x funktionsfähig … und schon ist das Limit da ... entweder ich baue das jetzt selbst nochmal nach oder ich überzeuge den Library-Entwickler das umzubauen oder ich akzeptiere es ... Schwierig ... :-)

Naja, wir schauen einfach mal wie es weitergeht und nehmen jedes Feedback von "falschen" Abhängigkeiten und versuchen Sie weg zu machen ,,,

Community Forum

NEWS

Update Node-js V4.x auf V6.x

Support us

669

32.4k

81.5k

1.3m