NEWS
Änderungen iob CLI/Installer/Fixer mit Root Accounts
-
Habe die Variante mit dem Reboot gewählt, denn man weiß "jeder boot tut gut"
Das Einzige war, dass der iobroker-MQTT-Adapter dem Zigbee2mqtt Server für den Zigbee gesteuerten Strahler in der Garagenauffahrt während des Hochfahrens des iobroker ein "Mach Aus" geschickt hat.
Mein Sohn hat daraufhin geschimpft wie ein Rohrspatz, weil er gerade einen Zahnriemen am Auto wechselt, und das Licht braucht ;-)Gibt es wohl ein wenig Fummelei, um das zu stabilisieren ...
@martinp sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Gibt es wohl ein wenig Fummelei, um das zu stabilisieren ...
Das ist aber dann dein Bier, die Skripte reboot sicher zu machen. Ich hatte das auch in einem Skript, das lief bei jedem Adapter-Neustart durch. Ich glaube da hat mir @paul53 geholfen.
-
Moin , habe das ganze mal versucht. Beim Ersten ausführen von "iob fix" konnte ich nichts auswählen. Also weder konnte ich einen neuen Nutzer anlegen noch das mit dem " Boot Target". Beim 2ten Durchlauf konnte ich dann beide Optionen auswählen.
Nun habe ich mir einen neuen Benutzer über "iob fix" anlegen lassen , nun ist das Problem das wenn ich von dort "iob fix" ausführen möchte er nach der Passwort Eingabe für sudo folgendes Meldet:hahne@ioBroker:~$ iob fix [sudo] Passwort für hahne: bash: /home/iobroker/.fix.sh: Keine BerechtigungPasswörter habe ich auch geändert, keine besserung.
Oder habe ich irgendwas nicht mitbekommen? -
Moin , habe das ganze mal versucht. Beim Ersten ausführen von "iob fix" konnte ich nichts auswählen. Also weder konnte ich einen neuen Nutzer anlegen noch das mit dem " Boot Target". Beim 2ten Durchlauf konnte ich dann beide Optionen auswählen.
Nun habe ich mir einen neuen Benutzer über "iob fix" anlegen lassen , nun ist das Problem das wenn ich von dort "iob fix" ausführen möchte er nach der Passwort Eingabe für sudo folgendes Meldet:hahne@ioBroker:~$ iob fix [sudo] Passwort für hahne: bash: /home/iobroker/.fix.sh: Keine BerechtigungPasswörter habe ich auch geändert, keine besserung.
Oder habe ich irgendwas nicht mitbekommen? -
@martinp sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Gibt es wohl ein wenig Fummelei, um das zu stabilisieren ...
Das ist aber dann dein Bier, die Skripte reboot sicher zu machen. Ich hatte das auch in einem Skript, das lief bei jedem Adapter-Neustart durch. Ich glaube da hat mir @paul53 geholfen.
@thomas-braun sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Das ist aber dann dein Bier, die Skripte reboot sicher zu machen. Ich hatte das auch in einem Skript, das lief bei jedem Adapter-Neustart durch. Ich glaube da hat mir @paul53 geholfen.
Es wird etwas offtopic - habe da jetzt so weit verfolgt, dass das ein Problem zwischen Lidl-Fluter und Zigbee2mqtt Server ist.
Das liegt eigentlich derzeit "Lose" herum (Schuko-Stecker mit Kabel für Tests angeschlossen), und wird nur bei Bedarf irgendwo angeschlossen, wo etwas Zusatz-Licht gebraucht wird.
Beim Einstecken geht der Strahler an, MELDET DAS ABER NICHT, das war der Zustand, als der iobroker LXC neu gestartet wurde.Habe da gerade nachgestellt, als ich den Strahler von der Fensterbank der Garagenenfahrt abgebaut, und im Arbeitszimmer wieder aufgebaut habe.
Für den zigbee2mqtt Server ist der Fluter aktuell aus (Schalters recht neben "Status"):
Das steht im Logging
22:05 Eingesteckt - Fluter ging von alleine an
22:13 Schalter bei zigbee2mqtt im Dashboard einmal Ein- und wieder Ausgeschaltet -> Fluter ging aus
info 2024-10-22 22:05:39z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:05:39+02:00","linkquality":191,"state":"OFF"}' info 2024-10-22 22:13:34z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:13:34+02:00","linkquality":190,"state":"OFF"}' info 2024-10-22 22:13:34z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:13:34+02:00","linkquality":190,"state":"ON"}' info 2024-10-22 22:13:36z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:13:36+02:00","linkquality":190,"state":"ON"}' info 2024-10-22 22:13:36z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:13:36+02:00","linkquality":190,"state":"OFF"}'Meine These ist, dass die Datenpunkte zwischen iobroker und zigbee2mqtt Server ein wenig "durchgerüttelt" wurden, als der Iobroker LXC durchgestartet wurde, da wurden wahrscheinlich die Datenpunkte einmal nach außen abgefeuert ...
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
@thomas-braun sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Das ist aber dann dein Bier, die Skripte reboot sicher zu machen. Ich hatte das auch in einem Skript, das lief bei jedem Adapter-Neustart durch. Ich glaube da hat mir @paul53 geholfen.
Es wird etwas offtopic - habe da jetzt so weit verfolgt, dass das ein Problem zwischen Lidl-Fluter und Zigbee2mqtt Server ist.
Das liegt eigentlich derzeit "Lose" herum (Schuko-Stecker mit Kabel für Tests angeschlossen), und wird nur bei Bedarf irgendwo angeschlossen, wo etwas Zusatz-Licht gebraucht wird.
Beim Einstecken geht der Strahler an, MELDET DAS ABER NICHT, das war der Zustand, als der iobroker LXC neu gestartet wurde.Habe da gerade nachgestellt, als ich den Strahler von der Fensterbank der Garagenenfahrt abgebaut, und im Arbeitszimmer wieder aufgebaut habe.
Für den zigbee2mqtt Server ist der Fluter aktuell aus (Schalters recht neben "Status"):Das steht im Logging
22:05 Eingesteckt - Fluter ging von alleine an
22:13 Schalter bei zigbee2mqtt im Dashboard einmal Ein- und wieder Ausgeschaltet -> Fluter ging aus
info 2024-10-22 22:05:39z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:05:39+02:00","linkquality":191,"state":"OFF"}' info 2024-10-22 22:13:34z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:13:34+02:00","linkquality":190,"state":"OFF"}' info 2024-10-22 22:13:34z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:13:34+02:00","linkquality":190,"state":"ON"}' info 2024-10-22 22:13:36z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:13:36+02:00","linkquality":190,"state":"ON"}' info 2024-10-22 22:13:36z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Lidl Fluter', payload '{"brightness":254,"color":{"x":0.4599,"y":0.4106},"color_mode":"color_temp","color_temp":370,"last_seen":"2024-10-22T22:13:36+02:00","linkquality":190,"state":"OFF"}'Meine These ist, dass die Datenpunkte zwischen iobroker und zigbee2mqtt Server ein wenig "durchgerüttelt" wurden, als der Iobroker LXC durchgestartet wurde, da wurden wahrscheinlich die Datenpunkte einmal nach außen abgefeuert ...
Ja, ist komplett OT. Bitte eigenen Thread eröffnen.
-
hahne@ioBroker:~$ ls -la /home/ ls -la /home/iobroker/.fix.sh insgesamt 16 drwxr-xr-x 4 root root 4096 22. Okt 10:11 . drwxr-xr-x 18 root root 4096 4. Okt 17:46 .. drwxr-xr-x 2 hahne hahne 4096 22. Okt 10:13 hahne drwx------ 5 iobroker iobroker 4096 22. Okt 10:08 iobroker ls: Zugriff auf '/home/iobroker/.fix.sh' nicht möglich: Keine Berechtigung hahne@ioBroker:~$ -
hahne@ioBroker:~$ ls -la /home/ ls -la /home/iobroker/.fix.sh insgesamt 16 drwxr-xr-x 4 root root 4096 22. Okt 10:11 . drwxr-xr-x 18 root root 4096 4. Okt 17:46 .. drwxr-xr-x 2 hahne hahne 4096 22. Okt 10:13 hahne drwx------ 5 iobroker iobroker 4096 22. Okt 10:08 iobroker ls: Zugriff auf '/home/iobroker/.fix.sh' nicht möglich: Keine Berechtigung hahne@ioBroker:~$sudo -u iobroker chmod 750 /home/iobroker/ -
@thomas-braun Funktioniert! Super danke.
Was hatte ich falsch gemacht :D ?@hahne sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Was hatte ich falsch gemacht ?
Relativ frische Installation? Ich glaube, in aktuellen Debiansen werden /home-Verzeichnisse für andere user als der eigene erstmal nicht freigegeben. Muss mal schauen, wie das bei aktuellen Installationen ausschaut.
-
@hahne sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Was hatte ich falsch gemacht ?
Relativ frische Installation? Ich glaube, in aktuellen Debiansen werden /home-Verzeichnisse für andere user als der eigene erstmal nicht freigegeben. Muss mal schauen, wie das bei aktuellen Installationen ausschaut.
@thomas-braun
Was heißt frisch :D ich glaube so ca. ein 3/4 Jahr. -
@hahne sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Was hatte ich falsch gemacht ?
Relativ frische Installation? Ich glaube, in aktuellen Debiansen werden /home-Verzeichnisse für andere user als der eigene erstmal nicht freigegeben. Muss mal schauen, wie das bei aktuellen Installationen ausschaut.
@thomas-braun Bei welchen Debiansen muss ich denn mit so einem Effekt rechnen?
Host: Fujitsu Intel(R) Pentium(R) CPU G4560T, 32 GB RAM, Proxmox 8.x + lxc Ubuntu 22.04
ioBroker (8 GB RAM) Node.js: 20.19.1, NPM: 10.8.2, js-Controller: 7.0.6, Admin: 7.6.3
Wetterstation: Froggit WH3000SE V1.6.6 -
@thomas-braun Bei welchen Debiansen muss ich denn mit so einem Effekt rechnen?
Das macht vermutlich jede Distro etwas anders.
Ich glaube, der iob-Installer biegt die Rechte passend, allerdings nur wenn der ausführende User nicht ohnehin schon 'iobroker' lautet. Deswegen ja auch immer der Hinweis, das 'iobroker' eine schlechte Idee für einen Standard-User ist.
-
rl5 ist die Voraussetzung für eine graphische Oberfläche. Ob tatsächlich eine installiert ist spielt da keine Rolle.
Kannst also dann gleich auf rl3 / multi-user setzen.(Am Rande: Auf ganz aktuellen systemd-Kisten gibt es die RunLevel nicht mehr, sind 'deprecated' und durch die boot.targets ersetzt worden):
[thomas@roamer ioBroker]$ who -r [thomas@roamer ioBroker]$ systemctl get-default graphical.target [thomas@roamer ioBroker]$@thomas-braun sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Ich nutze ja die fertigen Images von Proxmox. Da ist das wohl noch nicht. Ich frag auch, weil du oben vonaktuellen systemd-Kisten gibt es die RunLevel nicht mehr
sprachst und ich aktuell den Runlevel 5 habe. Aber ich vermute mal, das gehört weniger hier hin als eher in einen Tomas-Braun_Linux-Kurs.:blush:
Host: Fujitsu Intel(R) Pentium(R) CPU G4560T, 32 GB RAM, Proxmox 8.x + lxc Ubuntu 22.04
ioBroker (8 GB RAM) Node.js: 20.19.1, NPM: 10.8.2, js-Controller: 7.0.6, Admin: 7.6.3
Wetterstation: Froggit WH3000SE V1.6.6 -
@thomas-braun sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Ich nutze ja die fertigen Images von Proxmox. Da ist das wohl noch nicht. Ich frag auch, weil du oben vonaktuellen systemd-Kisten gibt es die RunLevel nicht mehr
sprachst und ich aktuell den Runlevel 5 habe. Aber ich vermute mal, das gehört weniger hier hin als eher in einen Tomas-Braun_Linux-Kurs.:blush:
@rene55 sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
sprachst und ich aktuell den Runlevel 5 habe.
Dein System ist vermutlich auch nicht 'bleeding edge'. Das wird bei Debian erst mit dem kommmenden Release 'Trixie' im nächsten Jahr evtl. eingeführt. Debian mahlt ja bei sowas immer sehr langsam und vorsichtig.
Auf meinem Arch-Linux Laptop gibt es keine RunLevel mehr:[thomas@roamer ioBroker]$ who -r [thomas@roamer ioBroker]$ -
@rene55 sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
sprachst und ich aktuell den Runlevel 5 habe.
Dein System ist vermutlich auch nicht 'bleeding edge'. Das wird bei Debian erst mit dem kommmenden Release 'Trixie' im nächsten Jahr evtl. eingeführt. Debian mahlt ja bei sowas immer sehr langsam und vorsichtig.
Auf meinem Arch-Linux Laptop gibt es keine RunLevel mehr:[thomas@roamer ioBroker]$ who -r [thomas@roamer ioBroker]$@thomas-braun Mit 'bleeding edge' kann ich nichts anfangen - hab ich noch nie gehört. Ich bin da auf das angewiesen, was proxmox so anbietet, Arch-Linux gibt es da anscheinend nicht.
Host: Fujitsu Intel(R) Pentium(R) CPU G4560T, 32 GB RAM, Proxmox 8.x + lxc Ubuntu 22.04
ioBroker (8 GB RAM) Node.js: 20.19.1, NPM: 10.8.2, js-Controller: 7.0.6, Admin: 7.6.3
Wetterstation: Froggit WH3000SE V1.6.6 -
@thomas-braun Mit 'bleeding edge' kann ich nichts anfangen - hab ich noch nie gehört. Ich bin da auf das angewiesen, was proxmox so anbietet, Arch-Linux gibt es da anscheinend nicht.
OT: Arch Linux ist ein 'rolling release', d. h. da hast du meist innerhalb von wenigen Stunden/Tagen die neuste Sorftware auf dem Rechner. Mit allen Vor- und Nachteilen. Das ganze ist natürlich dann auch weniger gut getestet. Debian lässt die Software u. U. Jahre reifen und haut nur alle zwei Jahre ein Release raus. Das ist natürlich gut abgehangen und besser getestet, ideal im Serverbetrieb.
-
Das macht vermutlich jede Distro etwas anders.
Ich glaube, der iob-Installer biegt die Rechte passend, allerdings nur wenn der ausführende User nicht ohnehin schon 'iobroker' lautet. Deswegen ja auch immer der Hinweis, das 'iobroker' eine schlechte Idee für einen Standard-User ist.
@thomas-braun sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:
Ich glaube, der iob-Installer biegt die Rechte passend, allerdings nur wenn der ausführende User nicht ohnehin schon 'iobroker' lautet. Deswegen ja auch immer der Hinweis, das 'iobroker' eine schlechte Idee für einen Standard-User ist.
So ist es. Fix für den Fixer ist eingereicht. Inkl. 'useradd' und 'chpasswd'.
-
@dr-bakterius hab ich auch .. tja Jung @Thomas-Braun da bin ich nicht alleine mit... rekursion hin oder her
@arteck Okk ... also ich hab mal geschaut und die FIles in /opt/iobroker/* hat der fixer noch NIE von owner her geradegebogen ... der macht das nur im /home/iobroekr/-npm. Im /opt/iobroker werden default ACL gesetzt sodass die iobroker Gruppe immer zugreifen darf.
Wenn im Fixer log ein "ACL enabled: true" steht dann war das erfolgreich und es ist nicht mehr nötig da Owner zu fixen. Also Ist das ok wenn der Owner ggf anders ist. Es sollte so oder so keine Probleme geben. Falls doch müsste man nochmal schauen.
Ergo ... all fine
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@arteck Okk ... also ich hab mal geschaut und die FIles in /opt/iobroker/* hat der fixer noch NIE von owner her geradegebogen ... der macht das nur im /home/iobroekr/-npm. Im /opt/iobroker werden default ACL gesetzt sodass die iobroker Gruppe immer zugreifen darf.
Wenn im Fixer log ein "ACL enabled: true" steht dann war das erfolgreich und es ist nicht mehr nötig da Owner zu fixen. Also Ist das ok wenn der Owner ggf anders ist. Es sollte so oder so keine Probleme geben. Falls doch müsste man nochmal schauen.
Ergo ... all fine
Hier macht meine Kiste das aber:
echad@chet:/opt/iobroker $ getfacl ichgehoereroot # file: ichgehoereroot # owner: root # group: root user::rw- group::r-x #effective:r-- group:iobroker:rwx #effective:rw- mask::rw- other::r-- echad@chet:/opt/iobroker $ echo "Es lief der Fixer" Es lief der Fixer echad@chet:/opt/iobroker $ echad@chet:/opt/iobroker $ getfacl ichgehoereroot # file: ichgehoereroot # owner: iobroker # group: iobroker user::rw- group::r-x group:iobroker:rwx mask::rwx other::r--Edit:
Und auch fiiles, die zuvor ohne ACLs gewesen sind bekommen in /opt/iobroker via Fixer die neuen Gruppen verpasst:echad@chet:/opt/iobroker $ getfacl ichgehoereechad # file: ichgehoereroot # owner: echad # group: echad user::rw- group::rw- other::r-- echad@chet:/opt/iobroker $ iob fix ............ echad@chet:/opt/iobroker $ getfacl ichgehoereechad # file: ichgehoereechad # owner: iobroker # group: iobroker user::rw- group::rw- group:iobroker:rwx mask::rwx other::r-- echad@chet:/opt/iobroker $ -
Bei mir immer noch das gleiche Problem:
haus@ioBroker:~$ iob stop Could not send "SIGTERM" to process 203: kill EPERM No "killall.sh" script found. Just stop. haus@ioBroker:~$ iob fix iobroker fix Execute the installation fixer script, this updates your ioBroker installation Options: --help Show help [boolean] haus@ioBroker:~$ iob startGerade gemerkt. Scheinbar bin ich auf JS Version 7.0.1
ioBroker auf NUC unter Proxmox; VIS: 12" Touchscreen und 17" Touch; Lichtsteuerung, Thermometer und Sensoren: Tasmota (39); Ambiente Beleuchtung: WLED (9); Heizung: DECT Thermostate (9) an Fritz 6690; EMS-ESP; 1 Echo V2; 3 Echo DOT; 1 Echo Connect; 2 Echo Show 5; Unifi Ap-Ac Lite.
810
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge