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

[Thomas Braun]

@tilly sagte in Nach Nodejs Update kein Adapter mehr updatebar:

ENOTEMPTY: directory not empty, rename /opt/iobroker/node_modules/node-red-node-email/node_modules/encoding-japanese/src' -> '/opt/iobroker/node_modules/.node-red-node-email-1lk8B7Gi/node_modules/encoding-japanese/src

Das Spiel ist immer das gleiche...

rm -rf /opt/iobroker/node_modules/.node-red-node-email-1lk8B7Gi/node_modules/encoding-japanese/src

[tilly]

@thomas-braun

Habe ich gelöscht und wollte Alexa2 installieren, da sagt er mir ist up to date, komisch.

Als ich dann cloud aktualisieren wollte:

user@iobroker-ubuntu:/opt/iobroker$ iobroker upgrade cloud --debug

This upgrade of "cloud" will introduce the following changes:
==========================================================================
-> 4.2.1:
Used new version of socket library.
==========================================================================

Would you like to upgrade cloud from @4.2.0 to @4.2.1 now? [(y)es, (n)o]: y
Update cloud from @4.2.0 to @4.2.1
NPM version: 8.11.0
Installing iobroker.cloud@4.2.1... (System call)
npm ERR! code ENOTEMPTY
npm ERR! syscall rename
npm ERR! path /opt/iobroker/node_modules/abbrev
npm ERR! dest /opt/iobroker/node_modules/.abbrev-5eNud0FY
npm ERR! errno -39
npm ERR! ENOTEMPTY: directory not empty, rename '/opt/iobroker/node_modules/abbrev' -> '/opt/iobroker/node_modules/.abbrev-5eNud0FY'

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/iobroker/.npm/_logs/2022-07-22T11_25_03_406Z-debug-0.log
host.iobroker-ubuntu Cannot install iobroker.cloud@4.2.1: 217

und die ganzen Verzeichnisse mit.xyz sind auf einmal alle wieder da, obwohl iobroker die ganze zeit aus ist.

[Thomas Braun]

@tilly

Dann versuch die Roßkur, die @crunchip schon mal vorgestellt hat.

[haselchen]

@tilly

https://forum.iobroker.net/topic/56343/vorgehensweise-im-bezug-auf-update-node-js-16-probleme?_=1658397690595

schätze Du meinst den Thread ( @Thomas-Braun )

[mickym]

Na ja bevor ich ein Backup zurück sichern würde, würde ich eher meine Methode noch versuchen, das ist wesentlich weniger zeitaufwändig. Habs noch ergänzt bevor man das macht natürlich - Image oder komplettsicherung des Systems und IOB stop ( hab ich noch ergänzt).

[tilly]

@mickym

habe es wie du vorgeschlagen gemacht und es hat alles prima funktioniert.

wenn ich nun apt-get update mache erhalte ich folgendes:

user@iobroker-ubuntu:~$ apt-get update
Paketlisten werden gelesen... Fertig
E: Sperrdatei /var/lib/apt/lists/lock konnte nicht geöffnet werden. - open (13: Permission denied)
E: Das Verzeichnis /var/lib/apt/lists/ kann nicht gesperrt werden.
W: Problem beim Entfernen (unlink) der Datei /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied)
W: Problem beim Entfernen (unlink) der Datei /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied)

oder mache ich update und upgrade als root?

[Thomas Braun]

@tilly sagte in Nach Nodejs Update kein Adapter mehr updatebar:

oder mache ich update und upgrade als root?

Nein, nie direkt als root hantieren.
Das wird per sudo angeleiert:

sudo apt update
sudo apt full-upgrade

[tilly]

@thomas-braun

hab einen ssh key für user hinterlegt, womit ich mich per ssh automatisch anmelden kann. Wenn ich nun per sudo Behle ausführe, wird ja wieder das Passwort verlangt. Kann man das anders lösen?

[mickym]

@tilly man kann das Lösen, in dem man sudo so konfiguriert, dass man kein Passwort mehr braucht, aber ich bekomme glaube gleich Haue von Thomas.😉

Und wie Thomas beschrieben hat, kann man auf das get verzichten.

[Thomas Braun]

@tilly sagte in Nach Nodejs Update kein Adapter mehr updatebar:

Kann man das anders lösen?

Ja, kann man.
Nein, tut man nicht.

Die Verzeichnislöschorgie kann man übrigens mit dem Einzeiler automatisieren:

cd /opt/iobroker/node_modules
for i in $(ls -d .[^.]*-*/); do rm -rf ${i%%/}; done

[mickym]

@thomas-braun Muss aber jeder selbst wissen.

Ich habe wie gesagt die sudo Passwortabfrage deaktiviert. Ansonsten muss man halt die beiden Befehle als root machen. Sonst kann man eben mit sudo und passwortlosem ssh arbeiten. Das ist im Übrigen auch wichtig, wenn man mit dem Linux Control Adapter arbeiten will. Der kann dann nämlich auch automatisch Upgraden wenn man will und sich nicht mit root Rechten anmelden will.

[Thomas Braun]

@mickym sagte in Nach Nodejs Update kein Adapter mehr updatebar:

Muss aber jeder selbst wissen.

Erfahrungsgemäß weiß aber nur die absolute Minderheit damit gescheit umzugehen.
Deswegen mein allgemeiner Rat: Finger weg von der Userverwaltung und dem seitens der Distribution vorgesehenen Rechtemanagement. Das hat schon einen Sinn, das es so eingestellt wurde wie es 'ab Werk' eingestellt ist.

Ich würde da vielleicht allenfalls die sog. 'grace time' etwas höher setzen. In dieser Zeitspanne wird dann nicht erneut nach dem PW gefragt.

[mickym]

@thomas-braun Na ja wenn Du mit ssh Dich ohne Passwort verbinden willst, dann macht es halt nicht wirklich Sinn. Aber ich hab ja in einem anderen Thread schon mal gepostet, wie es geht und im Netz findet man ja auch genug Input. Ich hantiere lieber mit meinem pi und passwortlosem Sudo, als mit root auf entfernten Systemen und kann damit eigentlich einiges machen. So gibts inzwischen bei mir gelben Alarm wenn Updates anstehen. ;)

[Thomas Braun]

@mickym

Im Netz findet man alles. Auch wie man z.B. nodejs irgendwie an allem vorbei in die Keramik donnert.
Da bin ich ja Leid gewohnt.

[mickym]

@thomas-braun sagte in Nach Nodejs Update kein Adapter mehr updatebar:

Im Netz findet man alles. Auch wie man z.B. nodejs irgendwie an allem vorbei in die Keramik donnert.
Da bin ich ja Leid gewohnt.

Ja gebe Dir da Recht. Mit der Zeit bekommt man aber bissi Übung - Gutes von Schlechtem zu unterscheiden. Insbesondere ein Filter, der Posts von anno dazumal rausfiltert, sollte man in der Regel nutzen.

In diesem Fall, wenn man ohne PW über SSH auf ein entferntes System zugreifen will, dann macht es auch Sinn, das Passwort von sudo für diesen EINEN User zu disablen. - Ist halt meine Meinung - Du bist allerdings hier der Fachmann im Vergleich zu mir - und trotzdem müssen wir ja nicht immer gleicher Meinung sein ;) - bzw. muss ich Deiner Meinung sein, weil Du auf diesem Gebiet die höhere Kompetenz hast. (Gibt ja noch so 1-2 Punkte, wo wir unterschiedliche Auffassungen haben. ;) )

[Thomas Braun]

@mickym

Ich gehe jetzt Mal davon aus, dass der use case 'Es reden Maschinen miteinander' beim TE nicht vorliegt.
Und selbst dann würde man diesen Maschinenuser per sudoers auf das beschränken, was der halt machen können darf.

[tilly]

ok eine Frage noch. Nutze momentan Ubuntu 18.04.6 LTS
Beim Einloggen erhalte ich die Meldung zum Update auf 20.04.4 LTS. Ist das so einfach zu machen?

New release '20.04.4 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

[mickym]

@tilly da bin ich leider raus. Ich habe ja nur debian auf dem Raspberry und das ist ja ein richtiges Release Update, also als ob Du Windows 10 auf Windows 11 upgradest. Das kann ggf. böse enden. Würde ich vielleicht schon mal machen. Aber nur mit Komplettsicherungen und da bist glaub länger beschäftigt um sicher zu stellen, dass alles wieder läuft. Aber irgendwann wirst Du wohl in diesen Apfel beißen müssen.

[Thomas Braun]

@tilly

Theoretisch ja.
In der Praxis können Fallstricke lauern.

Je mehr am System 'rumgefrickelt' würde, umso höher die Wahrscheinlichkeit da in Stolperfallen zu laufen

Auch deswegen halt der Rat, das System nicht mutwillig auf links zu drehen
Das 'do-release-upgrade-Skript' geht nämlich von einem unverfummelten System aus.