Änderungen iob CLI/Installer/Fixer mit Root Accounts

[Thomas Braun]

@meister-mopper sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:

Bei mir liegen die Rechte nach iob fix auch durchgängig beim user iobroker.

So soll es sein.

[MartinP]

Mir wurde beim Aufruf von iob diag erzählt ich hätte eine Linux Installation mit grafischer Oberfläche, ob das geändert werden solle.
Der Dialog war aber verstümmelt, und ich konnte nix eingeben ...

ist garantiert keine solche Installation (siehe Signatur)

[Thomas Braun]

@martinp sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:

ich hätte eine Linux Installation mit grafischer Oberfläche,

Eine Linux-Installation, deren BootTarget graphical.target ist.

Der Dialog war aber verstümmelt, und ich konnte nix eingeben ...

Eingeben kannst du da auch nix. Und inwiefern war die Ausgabe verstümmelt?

[Meister Mopper]

@martinp

runlevel 5?

thomas@iobroker:~$ who -r
         Runlevel 3   2024-10-16 18:23

[Thomas Braun]

who -r
systemctl get-default

zeigt das Target bzw. das run level an.

[Meister Mopper]

@martinp

Ich muss das bei meinen Proxmox LXC und VM nach der Erstellung auch immer nachträglich richtig stellen:

sudo systemctl set-default multi-user.target

Anschließend ein sudo reboot und alles ist fein.

[Thomas Braun]

@meister-mopper sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:

Anschließend ein sudo reboot und alles ist fein.

Oder ein

sudo systemctl isolate multi-user.target

[MartinP]

@meister-mopper

martin@iobroker-test-sicher:~$ who -r
         run-level 5  Sep 26 13:10
martin@iobroker-test-sicher:~$

[Meister Mopper]

@martinp

Dann weißt du, was zu tun ist

[Thomas Braun]

@martinp

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]$

[Meister Mopper]

@thomas-braun sagte in Änderungen iob CLI/Installer/Fixer mit Root Accounts:

Oder ein

sudo systemctl isolate multi-user.target

Ja, für Linux-Bildung bist Du natürlich prädestiniert!

[MartinP]

@meister-mopper Erstmal hatte der LXC-Container mit dem Reboot "zu tun"

Jetzt aber feddich

martin@iobroker-test-sicher:~$ who -r
         run-level 3  Oct 22 19:12

edit:

martin@iobroker-test-sicher:~$ systemctl get-default 
multi-user.target

[Thomas Braun]

@martinp
So sollte es auf einem headless server sein.

Edit: iob diag sollte jetzt auch nix mehr zu moppern haben. Jedenfalls nichts bezüglich des boot.targets

[MartinP]

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 ...

[Thomas Braun]

@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.

[hahne]

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 Berechtigung

Passwörter habe ich auch geändert, keine besserung.
Oder habe ich irgendwas nicht mitbekommen?

[Thomas Braun]

@hahne

ls -la /home/
ls -la /home/iobroker/.fix.sh

sagt?

[MartinP]

@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 ...

[Thomas Braun]

@martinp

Ja, ist komplett OT. Bitte eigenen Thread eröffnen.

[hahne]

@thomas-braun

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:~$