Monatsrückblick Januar/Februar 2026 ist online!

[AlCalzone]

@0018 bei neuen Installationen oder nach verwenden des fixers ist sudo so gut wie nie nötig oder sogar schädlich

Als iobroker kannst du dich nur über Umwege anmelden und das sollte ebenfalls nur in Ausnahmefällen nötig sein. Zb zum generieren von ssh keys für den User.
Mit den iobroker Kommandos und npm ohne sudo kannst du ganz normal als der Standard user arbeiten

[Homoran]

@ICEMAN sagte in Neue Installationsroutine und neue Anleitungen (für Linux-basierte Systeme):

die Links zu den Anleitungen verlaufen im Nirvana.

https://www.iobroker.net/#de/documentation/install/linux.md

[CKMartens]

Hallo,

die Links zu den Installationsroutinen führen ins leere. Es kommt die Meldung

Cannot GET /docu/

[Homoran]

@CKMartens sagte in Neue Installationsroutine und neue Anleitungen (für Linux-basierte Systeme):

Hallo,

die Links zu den Installationsroutinen führen ins leere. Es kommt die Meldung

Cannot GET /docu/

Den post über deinem hast du gesehen?

[CKMartens]

@Homoran sagte in Neue Installationsroutine und neue Anleitungen (für Linux-basierte Systeme):

@CKMartens sagte in Neue Installationsroutine und neue Anleitungen (für Linux-basierte Systeme):

Hallo,

die Links zu den Installationsroutinen führen ins leere. Es kommt die Meldung

Cannot GET /docu/

Den post über deinem hast du gesehen?

Ja, habe ich. Da aber neue mögliche Anwender erstmal beherzt auf den Link klicken, wäre es aber evtl nicht evtl. besser direkt dort einen hinweis zu geben. Sind j noch mehre Links im Forum die in die leere Doku laufen. Hab es nur gestern mitbekomme wie ein Bekanter versucht hatte ioBroker zu instalieren und dann die Doku eben nicht gefunden hat. Wäre eben für neue User einfacher (und IMHO sieht es unprofessionel aus wenn Dokus in Nirvana laufen)

[Homoran]

@CKMartens sagte in Neue Installationsroutine und neue Anleitungen (für Linux-basierte Systeme):

Da aber neue mögliche Anwender erstmal beherzt auf den Link klicken,

Kannst du bitte genau sagen welchen du meinst?
Hier sind bestimmt Hunderte Links im Forum

[CKMartens]

@Homoran Kannst du bitte genau sagen welchen du meinst?
Hier sind bestimmt Hunderte Links im Forum

Wenn jemand neues den ersten Post liest weil er eine Anleitung zur Installation sucht, wird er auf diese klicken und ins nirgendwo geführt. Daher wäre es ja gut wenn die zwei Links aus dem Posting geändert oder gelöscht werden. Darum geht es mir.
Es wärewwünschenswert wenn die anderen Links hier im Forum zur "alten" Doku abgefangen werden könnten was aber sicher nicht so einfach geht. Ist halt für einen User, der in einem Post auf die vermeintliche ioBroker Doku hingewiesen wird, verwirrend. Ist aber meine Meinung.

Hab nur den Eindruck das solche Kritik hier immer sehr persönlich genommen wird.

Also entschuldige bitte wenn ich irgendjemand auf den Schlips getreten habe.

[Homoran]

@CKMartens sagte in Neue Installationsroutine und neue Anleitungen (für Linux-basierte Systeme):

Es wärewwünschenswert wenn die anderen Links hier im Forum zur "alten" Doku abgefangen werden könnten was aber sicher nicht so einfach geht.

In allen Punkten korrekt!
Jeder link muss manuell geändert werden.

Deswegen nochmal meine Frage. Welchen link soll ich anpassen?

[rmohrs]

@Homoran

z.B die 2 Links aus dem ersten Post funktionen nicht

es kommt die Meldung Cannot GET /docu/

*Dahingehend haben wir auch die Doku entsprechend angepasst und diese auch gleich gesplittet. Es gibt nun Anleitungen für

http://www.iobroker.net/docu/?page_id=8323&lang=de

http://www.iobroker.net/docu/?page_id=8327&lang=de

Für diejenigen unter euch, die bei der scriptbasierten Installation*

Gruss Rainer

[Homoran]

@rmohrs

Danke für diese Info!

Ich bin gerade etwas verwirrt, was ich jetzt mit diesem Thread machen soll.

Die Links führen bei mir auf die identische Doku ;-)
Auch wenn es zwei verschiedene Pages sind.

Die Ursache ist, dass der "alte Weg" nicht mehr unterstützt wird.

• Wenn ich jetzt den kompletten ersten Post so modifiziere, dass es an alle (im Moment) aktuell gültigen Gegebenheiten zutrifft, werden viele folgende Posts aus dem Zusammenhang gerissen.

• Nur einen entsprechenden Hinweis im ersten Post hilft all denen nicht, die über die Suche mitten im Thread landen

• Den gesamten Thread löschen ist IMHO nicht gerechtfertigt

• einen weiteren Thread aufmachen bringt dauerhaft auch nichts, da ihn das gleiche Schicksal erleiden wird.

Mittelfristig werden wir wieder unter Announcements eine Linksammlung aufnehmen mit den wichtigsten Links zu der neuen Doku
Diese muss aber erst einmal komplett werden.

[AlCalzone]

@Homoran sagte in Neue Installationsroutine und neue Anleitungen (für Linux-basierte Systeme):

Die Links führen bei mir auf die identische Doku

Die Links führen zu einer Fehlerseite:

[Homoran]

@AlCalzone
Möglich ;-)
Aber das ist nicht mein "Problem".

[mimue]

Hallo allerseits,

ich habe es gerade geschafft iobroker unter Arch Linux zu installieren. Das Skript ist an dieser Stelle etwas ignorant :-(

Falls jemand das Gleiche versuchen möchte, hier die Abweichungen, die zu beachten sind:

ROOT_GROUP=wheel
Paketmanager pacman
Paket installieren mit: pacman -S paketname

Pakete Debian - ARCH Linux

acl - acl
sudo - sudo
libcap2-bin - libcap
build-essential - base-devel
libavahi-compat-libdnssd-dev - avahi und nss-mdns
libudev-dev - libudev0
libpam0g-dev - pam
pkg-config - pkgconf
curl - curl
unzip - unzip

Bei der Installationsvorbereitung gemäß "https://www.iobroker.net/#de/documentation/install/linux.md" fällt auf, daß nodejs nicht existiert (im Beispiel ist es wohl umgekehrt, nodejs existiert und node fehlt, das wird durch ein symbolisches Link behoben, kein Wunder zeigen beide die gleiche Versionsnummer.) Da ich nicht sicher bin, ob es notwendig ist, beide zu haben, habe ich sicherheitshalber ein Link angelegt, allerdings andersherum: ln -s /usr/bin/node /usr/local/bin/nodejs

Anschließend das Installations-Skript als einfacher Benutzer aufgerufen.

Alles läuft mehr oder weniger ereignislos durch, einzig eine Fehlermeldung von make

gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/usr/lib/node_modules/node-gyp/lib/build.js:190:23)
gyp ERR! stack at ChildProcess.emit (events.js:193:13)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:255:12)
gyp ERR! System Linux 5.1.16-arch1-1-ARCH
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /opt/iobroker/node_modules/unix-dgram
gyp ERR! node -v v11.15.0
gyp ERR! node-gyp -v v5.0.0
gyp ERR! not ok

stört das Bild. Es scheint sich aber nicht weiter auszuwirken. Anmeldung mit dem Webbrowser und Einrichtung klappen gut.

Warum im Skript eine lange TODO: Bemerkung bezüglich Ausführung als root steht, statt einfach nach IS_ROOT=true ein exit 1 einzufügen erschließt sich nicht wirklich.

Man könnte das Skript schon ein wenig freundlicher für nicht Debian-basierte Distros gestalten, ich bringe mich da gerne ein, wenn erwünscht.

MiMue

[AlCalzone]

@mimue sagte in Neue Installationsroutine und neue Anleitungen (für Linux-basierte Systeme):

Man könnte das Skript schon ein wenig freundlicher für nicht Debian-basierte Distros gestalten, ich bringe mich da gerne ein, wenn erwünscht.

Gerne! Auf solche Hilfe sind wir angewiesen. Ich habe selbst nur einen Raspberry Pi zum Testen. Wie kann ich im Skript erkennen, dass es sich um ein Arch Linux handelt? Bisher prüft das Skript die Ausgabe von uname -a.

@mimue sagte in Neue Installationsroutine und neue Anleitungen (für Linux-basierte Systeme):

Warum im Skript eine lange TODO: Bemerkung bezüglich Ausführung als root steht, statt einfach nach IS_ROOT=true ein exit 1 einzufügen erschließt sich nicht wirklich.

Die Anmerkung stammt noch aus einer der ersten Installer-Versionen. Inzwischen ist es egal ob man den Installer als root startet - ioBroker wird am Ende immer als non-root ausgeführt.

[mimue]

@AlCalzone

uname -r gibt bei mir "5.1.16-arch1-1-ARCH" zurück, ich bin allerdings nicht sicher, ob das Format allgemeingültig ist, da müßte man bei RedHat, SuSE etc. mal forschen.

Nachtrag: Auf "https://en.opensuse.org/SDB:SUSE_and_openSUSE_Products_Version_Outputs" wird mit cat /usr/lib/os-release gearbeitet. Das scheint einigermaßen standardisiert zu sein, ich erhalte damit:

cat /usr/lib/os-release

NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="0;36"
HOME_URL="https://www.archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux

Damit läßt sich sicher einiges anfangen.

MiMue

[AlCalzone]

@mimue Was ist mit uname -a?

[mimue]

@AlCalzone

uname -a

Linux iBASE 5.1.16-arch1-1-ARCH #1 SMP PREEMPT Wed Jul 3 20:23:07 UTC 2019 x86_64 GNU/Linux

Das wird aber ein bißchen aufwendig zu extrahieren, einfacher wäre doch einfach mit whereis oder einem Testaufruf des Paketmanagers festzustellen welches Paketsystem verwendet wird:

openSuSE zypper, ARCH Linux pacman, RedHat rpm, Debian apt, etc.

Beispiel:

[remoteadmin@iBASE tmp]$ apt
-bash: apt: Kommando nicht gefunden.
[remoteadmin@iBASE tmp]$ pacman
Fehler: Keine Operation angegeben (benutzen Sie -h für Hilfe)

oder

[remoteadmin@iBASE tmp]$ whereis apt
apt:
[remoteadmin@iBASE tmp]$ whereis pacman
pacman: /usr/bin/pacman /etc/pacman.d /etc/pacman.conf /usr/share/pacman /usr/share/man/man8/pacman.8.gz

Siehe auch: "https://de.wikipedia.org/wiki/Paketverwaltung"

MiMue

[AlCalzone]

@mimue Das muss ich mir mal gut überlegen. Bisher treffen wir die Unterscheidung nach Linux/OSX/FreeBSD weil diese sich teils unterschiedlich verhalten und unterschiedliche Befehle für Userverwaltung/Installation etc nötig sind.

[mimue]

@AlCalzone

Na ja, Linux Systeme sollten sich schon gleich verhalten, tun sie aber meistens nicht wirklich. Viele Distributionen nehmen Debian als Basis, verändern aber schon auch einiges in der Administration und in der Bereitstellung von Paketen.

Auch die Verwendung von Verzeichnissen, sudo, etc. ist teilweise recht eigenwillig gelöst. Man kann sicher nicht alles abdecken. Vielleicht wäre statt eines Skripts für alles (wer könnte / wollte das pflegen ? ) einfach eine Prüfung hilfreich, die bei Erkennen eines nicht-Debian Systems eine Nachricht mit Hinweis auf die Anforderungen und Tipps für händisches Einrichten ausgibt und dann abbricht.

Ich persönlich setzte am Liebsten ARCH Linux ein (auch auf SBC) weil es keine Release-Wechsel kennt und sich weitestgehend an allgemein akzeptierte Regeln hält.

Wenn man nur auf uname testet, läuft das Skript auf jedem Linux-Dialekt und bringt möglicherweise mehr Nacharbeit ins Spiel als der ungeübte Nutzer (sind wohl eh die meisten, ich schließe mich da nicht aus) verkraften kann oder will.

[mimue]

@AlCalzone

Ich habe nach meiner letzten Mitteilung noch ein wenig mit Docker gespielt. Möglicherweise wäre das auch eine Alternative: Ein erwiesen lauffähiges Docker-Image zur Verfügung zu stellen. Offenbar habt Ihr damit schon gearbeitet, sonst wäre die Variante ja nicht im Installations-Skript enthalten.

Man könnte sicherstellen, daß alle Vorbedingungen erfüllt sind, wäre die Abhängigkeit von Plattformen, System- und Paketupdates los, und könnte bei der Fehlersuche - natürlich wäre auch das Docker-Image fehlerbehaft :-) - von einer gegebenen Umgebung ausgehen.

P.S. wofür wird eigentlich unix-dgram gebraucht ? Lohnt es sich in diesen Installationsfehler Energie zu investieren ?