Umfrage zu gewünschten oder genutzten Hardware-Plattformen

[Prof.Mobilux]

Ich kenne mich mit Docker nicht sonderlich gut aus, meine aber Christian Fenzl oder svethi hatten sich schon einmal damit beschäftigt. Aus irgendwelchen Gründen ging das nicht so einfach...

[svethi]

Docker ist keine Vollvirtualisierung. Es wurde eher entwickelt um eine bestimmte Anwendung in einem Container laufen zu lassen. Einiges geht im Docker gar nicht. Darunter z.B. ein einfacher Neustart. Vielleicht ist es irgendwie möglich, aber halt nicht auf normalem Wege und ich glaube kaum, dass wir jetzt dafür ein spezielles System stricken. Des Weiteren gibt es viele Plugins die auf Hardware zugreifen, was hier ein Problem ist und riesigen Supportaufwand bedeutet würde. Das Dateisystem des Docker ist eine reine Katastrophe. Da mal eben einfach auf die SD gucken und eine Datei rauskopieren geht auch nicht. Das ist ein weiterer Grund, der das unmöglich macht das zu supporten.

[Prof.Mobilux]

Ich wusste doch: da war irgendwas... 😀

[Gagi]

Das seht ich auch so.
Ein gutes Beispiel für das Hardware Problem bei Docker ist USB. Das Gerät zB ttyUSB0 muss an den Container durchgereicht werden. Sobald das Gerät abgesteckt wird und wieder angesteckt wird, ist es im System als ttyUSB1 vorhanden, der Container kriegt das nicht mit. Der Container kann auch wegen dem Mapping auch nicht ohne ttyUSB0 starten. Mit Hardware macht Docker keinen Spass.

[orli]

@gagi

Dein Problem ließe sich aber mit udev auf „Node“ Ebene lösen, indem man das USB Device an einen Namen bindet… nichtsdestotrotz, Docker für Hardware ist Müll.

[Christian Fenzl]

LoxBerry als Container nicht geben. LoxBerry ist im Großen und Ganzen ein Webinterface für ein Betriebssystem. Es braucht keinen LoxBerry, wenn darunter kein Betriebssystem läuft.

Vielmehr müsste jeder Plugin-Entwickler sein Plugin als Container bereitstellen. Im Container alles, was zum Laufen benötigt wird, und um ein Webinterface anzuzeigen. Die Libraries und Web-Templates von LoxBerry müsste jeder mit in den Container nehmen.

Ein LoxBerry-Container hingegen, der sich verhält wie ein Raspberry oder eine VM, hat überhaupt keinen Sinn, weil damit das funktioniert, müsste der Container ein Betriebssystem betreiben - schließlich kann jedes Plugin beliebige Pakete nachinstallieren (die persistiert werden müssen), können Einstellungen am Betriebssystem verändern, ebenso wie Dateisystemrechte. Wenn ich das so haben möchte, dann starte ich eine VM.

Die Frage wäre, was soll denn ein LoxBerry-Container konkret tun? Ein Plugin kann er jedenfalls nicht betreiben.

lg, Christian

[Prof.Mobilux]

Wenn man sich die Umfrage anschaut, steht schon fest wie wir mit den Images weiter machen werden.

1. Docker wird es nicht geben - siehe Christian's Erläuterungen weiter oben
2. Unser derzeitiges Image wird auf Armbian (eventuell auch DietPi) umgestellt. Aktuell laufen wir auf Raspbian.
3. LoxBerry wird als Skript installierbar sein

Aktuell ist der LoxBerry quasi auf den Raspberry beschränkt, weil wir Raspbian (ein Betriebssystem, welches nur auf dem Raspberry läuft) einsetzen. Mit Umstellung auf Armbian (oder DietPi) als Betriebssystem kann der LoxBerry auf einen Schlag auf so gut wie allen Einplatinenrechnern und auch auf vielen Virtualisierungslösungen laufen. Das bringt uns vom Raspberry weg und öffnet z. B. die Welt der VMs.

Das Bereitstellen des Images ist für (unerfahrene) Nutzer extrem bequem und benötigt überhaupt keinen Zugriff auf der Linux Kommandozeile. Aber das Erstellen und die Pflege ist sehr zeitaufwendig. Wir werden daher für den LoxBerry zukünftig zwei offizielle und getestete Images bereitstellen:

1. Raspberry ab Version Pi2
2. VM für x64

Das erschlägt den größten Bedarf (siehe Umfrage). Aber alle Nutzer auf einer anderen Plattform, die ebenfalls von Armbian bzw. DietPi unterstützt werden, können sich den LoxBerry per Skript selbst installieren. Das ist nicht ganz so bequem wie als fertiges Images, aber für jeden mit grundlegenden Computerkenntnissen ebenfalls problemlos machbar. Somit können dann alle anderen mit "exotischerer" Hardware wie z. B. eines RockPi oder OrangePi den LoxBerry trotzdem relativ einfach installieren.

Der MS4H von hismastersvoice nutzt das gleiche Konzept zur Installation.

Falls wir uns für Armbian und nicht für DietPi entscheiden, werden allerdings alle Nutzer mit Pi1, Pi2, Zero1 halb auf der Strecke bleiben. Hierfür gibt es keine Images von Armbian mehr. Aber auch diese Raspberrys wären noch nutzbar, indem man das letzte Raspbian-Image (LoxBerry 3.0) installiert und dann per LoxBerry Update einfach weiter hochzieht.

So mal der Plan - jetzt brauchen wir nur noch die Zeit zur Umsetzung

[Prof.Mobilux]

Hallo Leute,

wer möchte kann unsere Installationsroutine testen! Damit ist es möglich den LoxBerry auf jedem Device, welches von DietPi unterstützt wird, on the fly zu installieren. Das Skript ist "Work in Progress" - testet es gerne und meldet Fehler, aber bitte nicht für irgendwelche Produktivsysteme verwenden.

Getestet haben wir aktuell auf einer VM (Virtual Box), einem Odroid und diversen Raspberrys.

So geht's:

1. DietPi auf eine SD-Karte flashen bzw. als VM konfigurieren. Download: https://dietpi.com/#download
2. Image booten und als root einloggen (entweder auf der Konsole oder per SSH über Putty): User: root Passwort: dietpi
3. Es läuft die Erstkonfiguration von DietPi ab. Das Setzen der Passwörter "canceln" und dann über "Install" das Minimalimage installieren lassen
4. Nach der Erstinstallation von DietPi könnt ihr die Installation von LoxBerry mit folgendem Befehl starten:

bash <(curl -s https://raw.githubusercontent.com/mschlenstedt/Loxberry/dietpi-test/install.sh) -b dietpi-test | tee /boot/install.log

5. Reboot
6. Per Browser http://loxberry oder eben über die IP des LoxBerrys den LoxBerry aufrufen.

Viel Spaß beim Ausprobieren! Bitte meldet mir Probleme direkt hier und hängt das Logfile mit an (liegt auf der /boot Partition, die auch über Windows erreichbar ist. Das Logfile heisst install.log).

[svethi]

Und auch auf Qemu/KVM

[svethi]

Für die Qenu/KVM User noch ein Tipp. Da bin ich nämlich auch drüber gestolpert. Wenn man das Image importiert, muss für die Festplatte explizit SATA angegeben werden. Sonst bootet der dietpi nicht.

[hismastersvoice]

Habe es mal auf die schnelle auf einer Proxmox VM installiert... ~38 Minuten, sind ein Haufen Pakete die installiert werden müssen.

Installation ist ohne Fehler durchgelaufen.
Ich kann aber keine Settings wie Sprache etc speichern.

RockPi4 installiert gerade noch... Wird auch noch eine ganze weile dauern.
Wie lange hat die installation bei euch gedauert? Raspi etc.

[Prof.Mobilux]

Die Paketinstallation muss ich noch etwas beschleunigen - er installiert jedes Paket einzeln, was extrem viel Zeit kostet. Pi2 braucht ein paar Stunden, Pi3 waren so ca. 2 Stunden.

Hast Du nach der Installation rebootet? Kannst Du mal schauen welche Dateirechte die Configdateien haben? ls -l /opt/loxberry/config/system

[Prof.Mobilux]

Ich kann es nachstellen. Die Dateirechte passen nicht.

[orli]

Hi,

Virtuozzo/KVM VM mit 4 CPU, SSD als Festplatte und 6 GB RAM:

- Installation läuft fehlerfrei durch

WE ARE DONE! :-)


You have to reboot your LoxBerry now!

Then point your browser to http://10.25.55.224 or http://loxberry

If you would like to login via SSH, use user 'loxberry' and pass 'loxberry'.
Root's password is 'loxberry', too (you cannot login directly via SSH).

Good Bye.



real    46m15,586s
user    34m12,431s
sys     4m38,637s

Dauer: ca. 3/4 Stunde.

[orli]

Die Meldung passt nicht ganz, fällt mir grad auf:

Root's password is 'loxberry', too (you cannot login directly via SSH).

Mein SSH im DietPi hab ich vorher konfiguriert und das Passwort geändert, dann macht der Installer wohl nichts mehr dran.

EDIT: Hab Pubkey-Auth am Start ... root PW ist sehr wohl geändert... grad auf der Konsole nochmal gecheckt. Passt also.

[Prof.Mobilux]

Ich habe die Installationsroutine jetzt in der Geschwindigkeit optimiert. Damit hat sich die Installationszeit um ca. die Hälfte reduziert:

VirtualBox 2 CPUs, 2 GB RAM, HDD:

Vorher:

real 63m43.598s
user 54m53.440s
sys 5m34.083s

Nach Optimierung:

real 32m54.446s
user 27m17.123s
sys 3m16.676s

Ein paar weitere Bugfixes sind auch noch hinzugekommen.

[orli]

Japp, ist flotter jetzt:

real 25m37,786s
user 16m17,419s
sys 2m33,253s

[hismastersvoice]

Installation in 22 Min auf der VM...

Rechte im Verzeichnis /opt/loxberry/config/system sind auf 0600 oder 0644 und können nicht beschrieben werden aus dem WebUI.
Nach chmod auf 0666 geht alles, bin mir aber nicht sicher ober der

Hier solltest du nochmal kurz schauen warum das nicht geht.

-rw------- 1 loxberry loxberry 11218 Feb  7 20:54 ca.cnf
-rw-r--r-- 1 loxberry loxberry  1192 Feb  7 21:15 general.cfg
-rw-r--r-- 1 loxberry loxberry  1029 Feb  7 20:54 general.cfg.default
-rw-r--r-- 1 root     root      2679 Feb  7 21:17 general.json
-rw-r--r-- 1 loxberry loxberry  2775 Feb  7 20:54 general.json.default
-rw------- 1 loxberry loxberry    47 Feb  7 21:17 htusers.dat
-rw------- 1 loxberry loxberry    47 Feb  7 20:54 htusers.dat.default
-rw------- 1 loxberry loxberry     7 Feb  7 20:54 is_arch_x86_64.cfg
-rw------- 1 loxberry loxberry    10 Feb  7 20:54 is_hwmodel_x86_64_pc.cfg
-rw------- 1 loxberry loxberry     4 Feb  7 20:54 is_x64.cfg
-rw------- 1 loxberry loxberry  9506 Feb  7 20:54 languages.default
-rw------- 1 loxberry loxberry    23 Feb  7 20:54 lockfiles.default
-rw-r--r-- 1 loxberry loxberry   128 Feb  7 21:17 loxberryid.cfg
-rw------- 1 loxberry loxberry   270 Feb  7 21:15 mail.json
-rw------- 1 loxberry loxberry   270 Feb  7 20:54 mail.json.default
drw------- 2 loxberry loxberry  4096 Feb  7 20:54 mosquitto
-rw-r--r-- 1 loxberry loxberry     0 Feb  7 21:17 mqttgateway.json
-rw-r--r-- 1 root     root        13 Feb  7 21:17 securepin.dat
-rw------- 1 loxberry loxberry    13 Feb  7 20:54 securepin.dat.default
-rw------- 1 loxberry loxberry   777 Feb  7 20:54 update-exclude.system
-rw------- 1 loxberry loxberry   251 Feb  7 20:54 update-exclude.userdefined​

/sbin/resetpermissions.sh

...
chmod -c 600 $LBHOMEDIR/config/system/*
chmod -c 644 $LBHOMEDIR/config/system/securepin.dat
chmod -c 644 $LBHOMEDIR/config/system/general.*​
...

Stimmt das so wie es das Skript macht?

[Prof.Mobilux]

Ja wir haben noch einen Bug eingebaut, der beim ersten Booten die general.json noch einmal als root bearbeitet. Daher stimmt dann der Besitzer danach nicht mehr. Hab's schon gefunden - Danke!

[loetman]

Ich habe es bei mir testweise auf eine VM in meiner Synology RS3614xs+ installiert.
Grundsätlich funktioniert es soweit.
Beim einrichten des MQTT Brokers ist mir aber aufgefallen, dass ich bei den Einstellungen nichts auswählen kann bei "Type sending the data to Miniserver":


weiter kann man auch keine Subscriptions eintragen bzw. werden sie nicht gespeichert und sind beim erneuten aufrufen der Seite weg.
Sehe ich das falsch, funktioniert das noch nicht? Den Miniserver habe ich in den Einstellungen konfiguriert.
Hat das mit den Berechtigungen zu tun die Hismastersvoice erwähnt hat? Bei mir ist das Verzeichnis 755.

[christoph_st]

Und, ergänzend, im chrome inspector der webseite sieht man folgende Exceptions, wenn man z.b. die Checkbox für "Send data via UDP" setzen möchte:

Uncaught TypeError: Cannot set properties of undefined (setting 'use_udp')
at HTMLInputElement.<anonymous> (mqtt-gateway.cgi:807:26)
at HTMLInputElement.dispatch (jquery-1.12.4.min.js:3:12444)
at r.handle (jquery-1.12.4.min.js:3:9173)
at Object.trigger (jquery-1.12.4.min.js:3:11573)
at HTMLInputElement.<anonymous> (jquery-1.12.4.min.js:3:18991)
at Function.each (jquery-1.12.4.min.js:2:2881)
at n.fn.init.each (jquery-1.12.4.min.js:2:846)
at n.fn.init.trigger (jquery-1.12.4.min.js:3:18967)
at HTMLInputElement.<anonymous> (jquery.mobile-1.4.5.js:8020:11)
at Function.each (jquery-1.12.4.min.js:2:2881)
(anonymous) @ mqtt-gateway.cgi:807
dispatch @ jquery-1.12.4.min.js:3
r.handle @ jquery-1.12.4.min.js:3
trigger @ jquery-1.12.4.min.js:3
(anonymous) @ jquery-1.12.4.min.js:3
each @ jquery-1.12.4.min.js:2
each @ jquery-1.12.4.min.js:2
trigger @ jquery-1.12.4.min.js:3
(anonymous) @ jquery.mobile-1.4.5.js:8020
each @ jquery-1.12.4.min.js:2
each @ jquery-1.12.4.min.js:2
_updateAll @ jquery.mobile-1.4.5.js:8016
(anonymous) @ jquery.mobile-1.4.5.js:835
_handleLabelVClick @ jquery.mobile-1.4.5.js:7956
(anonymous) @ jquery.mobile-1.4.5.js:835
h @ jquery.mobile-1.4.5.js:1138
dispatch @ jquery-1.12.4.min.js:3
r.handle @ jquery-1.12.4.min.js:3
trigger @ jquery-1.12.4.min.js:3
(anonymous) @ jquery-1.12.4.min.js:3
each @ jquery-1.12.4.min.js:2
each @ jquery-1.12.4.min.js:2
trigger @ jquery-1.12.4.min.js:3
o @ jquery.mobile-1.4.5.js:3496
p @ jquery.mobile-1.4.5.js:3507
dispatch @ jquery-1.12.4.min.js:3
r.handle @ jquery-1.12.4.min.js:3

mqtt-gateway.cgi:807 Uncaught TypeError: Cannot set properties of undefined (setting 'use_udp')
at HTMLInputElement.<anonymous> (mqtt-gateway.cgi:807:26)
at HTMLInputElement.dispatch (jquery-1.12.4.min.js:3:12444)
at r.handle (jquery-1.12.4.min.js:3:9173)

[christoph_st]

Ok, der Fehler ist gefunden.
Die Config ist in der Webseite leer:

<!-- RAW Config -->
<div style="display:none">
<div id="mqttconfig">{}</div>
<div id="udpinportconfig">11884</div>
<div id="extpluginsettings"></div>
<div id="Uselocalbroker">1</div>
</div>

Und damit wird später, im javascript code, diese mqttconfig als str dekodiert, leer, und es kommt dann im Folge immer zu Fehlern, wenn darauf zugegriffen werden will. Ich schau mal ob ich finde, wer/wo dieses mqttconfig setzt.

[christoph_st]

Der Bug ist gefunden und gelöst:

Das Configfile ist das "mqttgateway.json"
>more ./webfrontend/htmlauth/system/mqtt-gateway.cgi
my $cfgfile = "$lbsconfigdir/mqttgateway.json";
my $extplugindatafile = "/dev/shm/mqttgateway_extplugindata.json";
my $transformerdatafile = "/dev/shm/mqttgateway_transformers.json";

Dieses wird dann gelesen und zum Template gepusht:
# Push json config to template
my $cfgfilecontent = LoxBerry::System::read_file($cfgfile);
# $cfgfilecontent = jsescape($cfgfilecontent);
$template->param('JSONCONFIG', $cfgfilecontent);

Und landet dann in der HTML Seite:
>more mqtt-gateway.html
<!-- RAW Config -->
<div style="display:none">
<div id="mqttconfig"><TMPL_VAR JSONCONFIG></div>
<div id="udpinportconfig"><TMPL_VAR UDPINPORT></div>
<div id="extpluginsettings"><TMPL_VAR EXTPLUGINSETTINGS></div>
<div id="Uselocalbroker"><TMPL_VAR USELOCALBROKER></div>
</div>

Wo es dann gelesen wird:
// Parse config
cfgstr = $("#mqttconfig").text();
if( cfgstr ) cfg = JSON.parse(cfgstr);

Und schlließlich darauf zugegriffen wird:
else if (id.startsWith("Main.")) {
var idarray = id.split(".");
if(inputType === "checkbox") {
cfg.Main[idarray[1]] = $(this).is(":checked");



Das Config file war bei mir fast leer, es beinhaltete nur ein:
{}

Es reicht, das Config file zu editieren und sowas reinzuschreiben:

>vi /opt/loxberry/config/system/mqttgateway.json
{
"Main": {
"use_udp": true,
"use_http": true,
"convert_booleans": true,
"expand_json": true
}
}

und dann können die Felder im Webinterface bearbeitet werden.
lg!

[Jedrek]

Habs auf HyperV probiert - lief durch und Webinterface ist erreichbar. Waren gefühlt 10 Minuten. Wo habt ihr die genauen Laufzeiten vom Script her?

[Prof.Mobilux]

Mit time aufrufen.