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

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

@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

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

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