Diskussion zum neuen Installation-Fixer

Wildbill

Hi,

muss mich einfach mal für den Fixer bedanken. Seit guten 1 1/2 Jahren lief mein iobroker in einer VM (Virtualbox) unter Ubuntu 16.04 natürlich noch als root eingerichtet. Nachdem ich alle anderen VMs mittlerweile auf Ubuntu 18.04 hatte war gestern iobroker dran. Als erstes den Fixer drüber laufen lassen, was ohne Probleme ging. Anschliessend do-release-upgrade und den npm manuell auf 6.8.0 upgedated. Node und Nodejs waren schon auf 8.10.0. Danach liefen gerade mal der amazon.dash und tradfri-Adapter nicht mehr. Beim tradfri war es mit einem npm rebuild getan, beim dash gibt es bei github in den issues einen Tip, wie er ohne root läuft:
setcap cap_net_raw,cap_net_admin=eip /usr/bin/node
Das getan und schon läuft mein iobroker seit gestern Abend fehlerfrei unter neuem Ubuntu und nicht mehr mit root.
Besten Dank dafür!

Gruss, Jürgen

Negalein

@darkiop sagte in Diskussion zum neuen Installation-Fixer:

Mit außerhalb meint ihr ein extra Volume für /opt/iobroker?

So
Synology_Nega_3 - Synology DiskStation.png

apollon77

@Wildbill Welche Version vom installer/Fixer war es denn? Die Rechte für dash sollten schon drin sein seit ein paar Tagen .

Wildbill

Gute Frage, welche es war kann ich nicht sagen, aber eben die, die gestern Nachmittag/Abend unter https://raw.githubusercontent.com/ioBroker/ioBroker/stable-installer/fix_installation.sh aktuell war. Und der Dash-Adapter lief danach nicht, auch nicht nach einem rebuild, erst nachdem ich den setcap-Befehl ausgeführt hatte.
Der läuft bei mir in Version 0.3.1.

Gruss, Jürgen

apollon77

@Wildbill Poste mal bitte dein INSTALLER_VERSION.txt aus deinem iobroker Verzeichnis.

Wildbill

Du meinst vermutlich die INSTALLER_INFO.txt? Bitteschön:

Fixer version: 2019-03-01
Fix date 2019-03-03
ACL enabled: true
init system: systemd
Autostart: systemd

Die Installation erfolgte ursprünglich unter Ubuntu 16.04 im November 2017 als root, wie es damals auf der Homepage ausgeführt war, soweit ich mich erinnern kann.

Das Installerscript habe ich gestern zum Fix direkt per curl geholt, da hat er diese Version (1.3.) noch gezogen. Heute scheint es eine Version vom 3.3. zu geben, wenn ich es richtig gesehen habe. Vielleicht war ich ein paar Minuten zu früh dran gestern?
Egal, läuft ja nun alles problemlos.

Gruss, Jürgen

bergjet

@Matten said in Diskussion zum neuen Installation-Fixer:

@AlCalzone Stimmt, Zwave macht am meisten Probleme, alles andere läuft wirklich super stabil. Wäre toll wenn du die Zeit finden würdest

Dem schließe ich mich an. Habe immer wieder Probleme, dass der Port vergessen wird.

AlCalzone

Kann mir nicht vorstellen, dass das irgendwas mit dem Fixer zu tun hat. Das klingt mehr nach Konfiguration oder noch was anderem.

apollon77

@Wildbill Interessant. Da war an sich alles drin schon

Ein

getcap $(eval readlink -f $(which node))

nach dem installer/Fixer wäre cool ... aber naja

Wildbill

Ich kann es nicht sagen woan es lag, dass es nicht ging. Im Script (allerdings vom 3.3., das vom 1.3. finde ich nicht mehr) ist die Zeile drin.
Das von mir nach dem Lauf des Fixer aufgrund de Fehler gemachte npm rebuild im Dash-Ordner sollte da ja nichts dran ändern.
Mir fällt aber ein, beim rebuild kam es zu Zugriffsfehlern aufgrund fehlender root-Rechte (hatte kein sudo genommen da ja nach dem Fixer nicht mehr nötig sein sollte). Vielleicht war ja irgendwo noch ein Ordner involviert, den der Fixer nicht erreichte und der aufgrund meiner root-Installation root-Rechte hatte. Im home meines normalen Users gibt es da einen Ordner node-gyp der root gehört. Frag mich nicht, wo der her kommt...
Egal, Hauptsache läuft.

Gruss, Jürgen

KeWe3C

Hallo apollon77
Nachdem sich ein Adapter nicht installieren ließ, habe ich den Installation-Fixer angewandt. Die Installation klappte daraufhin zunächst ohne Fehler. Soweit die gute Nachricht.
Allerdings wird jetzt dem aus einem Script abgesetzten Befehl "sudo /home/pi/raspberry-remote/send 11111 1 0" die Ausführung verweigert:
"stderr: ....... sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben"
Ich vermute - leider habe ich hier keine Erfahrung - ein Rechteproblem (ioBroker ist nicht mehr root). Wie kann ich den Fehler vermeiden?
Könnte das auch einige andere Adapter betreffen?

AlCalzone

@KeWe3C Ich glaube das Thema hatten wir vor kurzem schon mal.
Im Prinzip hast du zwei Probleme:

raspberry-remote/send darf nicht mehr in /home/pi liegen, sondern muss für den User iobroker zugreifbar sein. D.h. am besten in /home/iobroker verschieben.
Für den User iobroker ist festgelegt, welche Befehle er per sudo ausführen darf. ~/raspberry-remote/send gehört nicht dazu. Ich glaube auch, dass es ohne sudo funktionieren müsste.

KeWe3C

Hallo AlCalzone
Vielen Dank für die Hinweise. Beide waren erfolgreich.

AlCalzone

D.h. es funktioniert jetzt?

KeWe3C

Richtig, es funktioniert.
Im gleichen Zusammenhang (?) gibt es weitere Probleme. Ich versuche mit LIRC zu arbeiten. Der LIRC-Adapter (https://github.com/t4qjXH8N/ioBroker.lirc) verbindet sich allerdings bei mir nicht mit dem lirc-dämon. LIRC läuft als root.
In früheren Installationen funktionierte das offenbar.
Be meiner ursprünglichen Frage "Könnte das auch andere Adapter betreffen?" hatte ich diesen Fall im Hinterkopf.
Es scheint, als hätte die neue Installationsart größere Auswirkungen.
Für einen Hinweis zur Lösung wäre ich dankbar.

Das LIRC-Problem hat sich geklärt. Ursache war das Zusammenwirken des Adapters mit dem LIRC-Dämon. Offenbar fehlte dem Adapter in einer HW-config-Datei die Angabe zum default-listen-port.
Jetzt funktioniert es soweit.
Sorry für die Umstände.

Dr. Bakterius

@apollon77 Leider geht es auch mit dem Fixer vom 5.3. noch nicht. Vom rpi2-Adapter kommen immer noch Fehlermeldungen bezüglich Zugriffsrechte. Zuerst vier, nach einer Neuinstallation des Adapters nur noch die cpu_frequency.

Hier das Log:

AlCalzone

@Dr-Bakterius Kannst du mal folgenden Fork des RPI2-Adapters von Github installieren? Da scheint ein Fix für dein Problem enthalten zu sein:
Installation aus eigener Quelle -> https://github.com/asgothian/ioBroker.rpi2/tarball/master

Dr. Bakterius

@AlCalzone Ändert leider nichts.

AlCalzone

Adapter-Upload und -Neustart durchgeführt? Würde mich schwer wundern, wenn der Fehler exakt identisch ist, da das Kommando ganz anders aussieht.

Dr. Bakterius

@AlCalzone Upload und Neustart natürlich durchgeführt.

Ich habe kein Log erstellt, aber es kam auch diesmal wieder:

No Value found for mem_gpu
No Value found for mem_arm
No Value found for cpu_voltage
No Value found for cpu_frequency

Man muss in den Instanzen-Einstellungen 'CPU' und 'Raspberry' deaktivieren um diese Fehler zu eliminieren.

NEWS

Diskussion zum neuen Installation-Fixer

Support us

924
Online

31.7k
Users

79.7k
Topics

1.3m
Posts

NEWS

Diskussion zum neuen Installation-Fixer

Support us

924Online

31.7kUsers

79.7kTopics

1.3mPosts

924
Online

31.7k
Users

79.7k
Topics

1.3m
Posts