Der kleine ioBroker/Linux-Werkzeugkasten
Wenn der ioBroker und/oder der Server, auf dem der ioBroker lebt, aus irgendwelchen Gründen anfängt herum zu zicken, sollte man da 'von Grund auf' sein System auf ein paar wesentliche Dinge abklopfen.
root login
Seit Jahren nicht mehr 'erlaubt', den root gibt es nur noch aus technischen Gründen im Hintergrund. (Ausnahme: Docker auf einer Synology, da gibt es zu meinem Leidwesen wohl leider keine gescheite Nutzerverwaltung). Sein System administriert man über einen Standarduser mit Standardrechten, der allerdings kurzzeitig über den vorangestellten Befehl
sudo
in die Rolle des roots schlüpfen kann, dann aber sofort wieder in seine Standardrolle zurückfällt. Das ist so auf einem üblichen System und wird auch nicht umgestellt, weil 'das blöd ist' oder 'nur kurz' oder aus 'auf meinem System darf ich alles, ich bin natürlich root'-Allmachtsphantasien. Und auch sudo selber wird nur dann verwendet, wenn es erforderlich ist. Nicht erforderlich ist es z. B. in Verbindung mit den Befehlen npm und iobroker! In der Kombination falsch eingesetzt kann es das System zerschießen!
Test:
Als Standarduser
groups
ausführen, dann sollte da ein Eintrag sudo zu finden sein. Wenn nicht, dann
Fix:
Als root
usermod -aG sudo USERNAME
und danach nie mehr als root einloggen!
Falls es noch gar keinen Standard-User geben sollte:
adduser username
usermod -aG sudo username
username ist durch den gewünschten Username zu ersetzen. Dabei verwendet man am besten nur Kleinbuchstaben und nennt den neuen user NICHT iobroker. Viele haben ja einen schönen Vornamen, den kann man da wunderbar verwenden.
Terminal für Faule
TAB-Taste: Befehle und Befehlsoptionen können u. U. per TAB-Taste von der bash vervollständigt werden. Keiner tippt solche Befehle vollständig ein.
Man tippt da nur die ersten paar Buchstaben wie z. B.
sudo syst TAB c TAB stat TAB iob TAB ein und das steht dann automagisch in der Konsole:
sudo systemctl status iobroker.service
Wenn man zufrüh tabbt und es noch mehrere Möglichkeiten der Ergänzung gibt schlägt die Konsole die verbliebenen Möglichkeiten auf und man kann sich daran weiterhangeln.
RunLevel 5 / graphische Oberfläche
Server werden aus diversen Gründen (Stabilität, Ressourcenverbrauch, Sicherheit) generell ohne graphische Oberfläche betreiben. Die dafür vorgesehene Betriebsart wird RunLevel 3 genannt. Nur wenn am Server ein Display für die Darstellung der Visualisierung des ioBrokers hängt wird ein Server ausnahmsweise in RunLevel 5 betrieben.
Test:
who -r
liefert RunLevel 3 zurück:
pi@raspberrypi:~ $ who -r
Runlevel 3 2021-03-03 22:01
Für andere Systeme kann man das per
echad@chet:~ $ systemctl get-default
multi-user.target
prüfen. Hier entspricht multi-user.target dem run level 3.
Fix:
Auf dem RaspberryPi am besten per
sudo raspi-config
in das Systemmenü gehen und dort die Menüpunkte
1 System Options Configure system settings
S5 Boot / Auto Login Select boot into desktop or to command line
B1 Console Text console, requiring user to login
auswählen.
Auf anderen Systemen stellt man das per
sudo systemctl set-default multi-user.target
ein.
Systemupdate
Seinen Debian-basierten Server (dazu gehört z. B. auch das Raspberry OS vom Raspberry Pi, Ubuntu, Armbian) aktuell und 'auf Stand' zu halten braucht es nur wenig Handwerkszeug. Die installierte Software (im Idealfall auch zusätzliche Pakete von Drittanbietern wie deconz, nodeJS von nodesource) wird sehr komfortabel und zentral über den Paketmanager gehandhabt.
Mit diesem 'Dreisatz' wird automatisch ein System inkl. aller über den Paketmanager installierten Software auf den aktuellen Stand gebracht:
sudo apt update
sudo apt dist-upgrade
sudo reboot
Das sollte man regelmäßig so ein oder zweimal im Monat machen. So bleiben die Upgrades übersichtlich und Sicherheitslücken werden einigermaßen zeitnah gestopft. Generell gilt: Je häufiger ich das mache desto weniger Trouble gibt es. 'Never change a running system' ist grundfalsch.
Test:
sudo apt update
sollte ungefähr so aussehen:
pi@raspberrypi:~ $ sudo apt update
Hit:1 http://deb.debian.org/debian bullseye InRelease
Hit:2 http://deb.debian.org/debian bullseye-updates InRelease
Hit:3 http://archive.raspberrypi.org/debian bullseye InRelease
Hit:4 http://security.debian.org/debian-security bullseye-security InRelease
Hit:5 https://repos.influxdata.com/debian bullseye InRelease
Hit:6 https://packages.grafana.com/oss/deb stable InRelease
Hit:7 https://deb.nodesource.com/node_14.x bullseye InRelease
InRelease
Fetched 5,536 B in 2s (2,348 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
Wichtig ist, dass hier keine Vermischungen von Releases enthalten sind. In obigem Beispiel kommen alle Pakete in der Version für das aktuelle Release von Debian namens 'Bullseye' daher. Da dürfen keine Einträge zu jessie, stretch oder buster oder sonstwas drinstehen. Allenfalls darf da noch 'stable' erwähnt werden, denn Bullseye ist z. Zt. das stable release von Debian. (Die release names von Ubuntu lauten anders, wichtig ist die Einheitlichkeit der release names)
Fix:
Wenn dort ausstehende Updates angezeigt werden
sudo apt update
sudo apt full-upgrade
sudo reboot
NodeJS
Wenn von vorneherein sauber installiert läuft das über das regelmäßig durchgeführte Systemupdate mit.
Test:
type -P nodejs && nodejs -v && type -P node && node -v && type -P npm && npm -v && type -P npx && npx -v && apt policy nodejs
schaut etwa so aus:
pi@raspberrypi:~ $ which nodejs && nodejs -v && which node && node -v && which npm && npm -v && apt policy nodejs
/usr/bin/nodejs
v14.16.0
/usr/bin/node
v14.16.0
/usr/bin/npm
6.14.11
/usr/bin/npx
6.14.11
nodejs:
Installiert: 14.16.0-1nodesource1
Installationskandidat: 14.16.0-1nodesource1
Versionstabelle:
*** 14.16.0-1nodesource1 500
500 https://deb.nodesource.com/node_14.x buster/main armhf Packages
100 /var/lib/dpkg/status
12.21.0-1nodesource1 500
500 https://deb.nodesource.com/node_12.x buster/main armhf Packages
10.24.0-1nodesource1 500
500 https://deb.nodesource.com/node_10.x buster/main armhf Packages
10.24.0~dfsg-1~deb10u1 500
500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
Wichtig und richtig ist:
nodejs liegt in /usr/bin
node liegt in /usr/bin
npm liegt in /usr/bin
und nicht in /usr/local/bin
und die Versionsnummer von nodejs und node ist a) gleich und b) gerade.
Ungerade Versionsnummern sind experimentelle Versionen und sollten nicht bzw. nur zu Testzwecken verwendet werden.
Gleiches gilt für npm und npx. Hier sind allerdings ungerade Versionsnummern okay.
Fix:
Bitte hier weiterlesen:
https://forum.iobroker.net/topic/35090/howto-nodejs-installation-und-upgrades-unter-debian
ioBroker-Verwahrort
Der vorgesehene Verwahrort für Adapter ist 'stable', der 'beta'-Bereich sollte nur in begründeten Fällen verwendet werden.
Test
iobroker repo list
schaut etwa so aus
pi@raspberrypi:~ $ iobroker repo list
stable : http://download.iobroker.net/sources-dist.json
beta : http://download.iobroker.net/sources-dist-latest.json
live-beta : http://iobroker.live/repo/sources-dist-latest.json
live-stable : http://iobroker.live/repo/sources-dist.json
Active repo: stable
Fix:
iobroker repo set stable
ioBroker-Adapterupdate
Im täglichen Betrieb funktioniert das ganz analog zum Systemupdate.
Über 'die Katze' bzw. aus dem github werden regulär gar keine Adapter installiert. Dort liegt Code, an dem gerade gearbeitet wird und nur der Developer kann sagen in welchem Zustand der Adapter von dort gerade ist. Diese Version setzt man nur in Absprache mit dem Developer für Testzwecke ein, nie dauerhaft produktiv.
Test:
iobroker update | grep -i updateable
sieht so aus
pi@raspberrypi:~ $ iobroker update | grep updateable
pi@raspberrypi:~ $
Fix:
iobroker upgrade
Updates des sehr zentralen js-controllers macht man etwas anders und richtet sich dann auch nach der jeweiligen Installation (Multihost z. B.). Das dann bitte in der entsprechenden Ankündigung im Forum aktuell nach lesen.
ioBroker Fixer
Eine 'Allzweckwaffe' bei merkwürdigem/zickigem Verhalten (Adapter bleibt rot in der Admin-Ansicht) auch einzelner Adapter (z. B. ble und radar2 sind da regelmäßige Kandidaten) ist ein
iobroker stop
iobroker fix
iobroker restart
Damit werden unter anderem z. B. bei einem Update verloren gegangene Rechte wieder eingeräumt und die Adapter können wieder funktionieren.
Den Fixer kann man auch 'auf Verdacht' mal laufen lassen.
Hilft alles nix
Wenn man sein System und den ioBroker auf die üblichen Dinge von oben abgeklopft hat und immer noch rumzickt postet man am besten relevante Auszüge aus dem log file des ioBrokers. Am liebsten ist es den Helfern im Forum, wenn das in dieser Form erfolgt:
Man öffnet eine zweite Konsolen-Sitzung über sein Terminalprogramm und schaut per
iobroker logs --watch | uniq
in das laufende log file rein. Dann agiert man in der ersten Konsole und/oder in der Weboberfläche des ioBrokers und versucht entsprechende Meldungen im log file zu provozieren. Diese kopiert man dann in sein Forumsthema rein, markiert die gesamte Ausgabe aus der Konsole und klickt dann das </> - Symbol über dem kleinen Editor-Fenster an. (Alternativ: Zuerst das </> anklicken, dann den Text aus der Zwischenablage zwischen die Steuercodes setzen).
Dann wird der Text in ähnlicher Form wie er auch in der Konsole erschien chronologisch korrekt dargestellt und ist wesentlich besser zu lesen.
Sieht dann so aus:
pi@raspberrypi:/opt/iobroker $ iobroker logs --watch | uniq
2021-03-06 03:31:22.078 - warn: mihome-vacuum.0 (1391) no answer received after after 3 times -> pause miIO.info try again in one hour
Gerne auch vollständig inkl. login prompt und Pfaden wie oben zu sehen. Auch aus diesen Informationen kann man ggf. was hilfreiches ableiten.
Bitte keine Screenshots des log files aus dem admin posten, die Funktion nutzt man nur für einen schnellen Blick in das log file um zu sehen ob da Handlungsbedarf besteht.
