Das war aber mit dem docker Image das man mit der 15 Tage Trial Version bekommt. Eine docker-compose Datei ist auch hier dabei.
Hi.
Ich habe eher den Eindruck, dass die ZIP-Datei (v.3.3.0) immer die gleiche ist?!
Aber wie auch immer man es angeht: Ich hatte ja schon versucht, die IP-Adresse mit dem Script zu ändern. Danach bin konnte ich den Server nicht mehr erreichen. Schade, dass es so kompliziert zu installieren ist … das hätten die wirkllich etwas übersichtlicher gestalten können – wer benötigt den Server denn schon unter localhost bzw so, dass alle Weiterleitungen immer auf localhost zeigen 
?
Michael
Hi Martin!
Bist du einen Schritt weiter gekommen? Ich hatte mir zwischendurch auch nochmal die alte Version 2.2.0 angesehen, da die noch wesentlich flotter war als jetzt V.3.3.0 – leider wird dort aber weiterhin die docker-IP anstelle der eth0-IP für die Android-Clients ausgespuckt 
Version 3.3.0 braucht echt eeeewig, bis es startklar ist (gefühlte 5 Minuten auf einem 4-Core-bare-metal-Rechner mit reichlich RAM). Liegt wahrscheinlich daran, dass das alles JAVA-Archive sind, oder? Da ich die Software nicht richtig testen kann, bin ich nach wie vor unschlüssig, ob sie für die Schule brauchbar ist und ob sie das kann, was sie verspricht zu können…
Schöne Grüße,
Michael
Hallo Martin und wer sich noch mit WSO2 beschäftigt,
ich hatte ja geschrieben, dass ich wso2iot-3.3.0.zip direkt auf “server” ausgepackt hatte.
Das lief für sich alleine auch so vor sich in, wenn ich über https://localhost:9443/devicemanagement darauf zugegriffen habe (Ja, auf meinem “server” läuft u. a. für so was LXDE … ist ja inzwischen nur noch eine Testumgebung).
Nachdem ich die entsprechenden Ports auf der internen Firewall (->linuxmuster-base) freigegeben und von Hand an etlichen Stellen localhost durch meine IP ersetzt hatte, konnte ich sogar einen Androiden registrieren. Nur holte der sich keine Pakete ab. Die Quelle für die “etlichen Stellen” weiß ich nicht mehr, war ja offenbar auch zumindest unvollständig.
Dann habe ich scripts/change-ip.sh in dem Archiv entdeckt. Nur wenn ich das darauf los lasse, funktioniert die Anmeldung danach nicht mehr (org.wso2.carbon.apimgt.integration.client.exception.APIMClientOAuthException: failed to retrieve oauth token using jwt). Es wird dabei ja ein neues Zertifikat erzeugt passend zum FQDN. Da die Recherche in WWW nach der Zeichenkette oben auf ein DNS-Problem hin deutete, habe ich es mit der IP, server und server.linuxmuster-net.lokal probiert. Mein DNS löst Kurznamen und FQDN korrekt auf.
Hat jemand eine Idee, was da schief läuft?
Läuft es im docker container richtig?
Muss man das Zertifikat doch so von Hand erzeugen?
https://docs.wso2.com/display/IoTS300/Configuring+WSO2+IoT+Server+with+the+IP+or+Hostname
Gruß Jürgen
Hi Jürgen.
Ähnliche Erfahrungen wie du hatte ich auch damit gesammelt. Leider ist die Installation alles andere als trivial und die Konfiguration ziemlich benuzter-unfreundlich. Daher habe ich das zunächst wieder beiseite geschoben. Schade eigentlich. Im Docker-Container lief es hier übrigens genauso wenig (rund). Sobald man die IP ändern wollte, ging immer etwas schief
Schöne Grüße,
Michael
Hallo Michael,
nicht aufgeben 
Wenn auch in Deiner Umgebung etwas schief geht, wenn Du die IP mit dem
Skript änderst, dann macht das Skript entweder beim Ändern von localhost
an X Stellen (was für ein Design, wo das so verstreut ist!) oder beim
Erstellen des Zertifikats etwas nicht, zuviel oder falsch.
Als ich localhost von Hand in mehreren xml geändert hatte, konnte ich
mich immerhin von einem Client aus an https://10.0.2.2:9443/devicemgt
anmelden. Dabei habe ich kein neues Zertifikat generiert.
Die Idee, das Skript abzubrechen, wenn es das Zertifikat erstellen will,
hat nicht weitergeführt. Da habe ich auch den Error 500 bekommen.
Der nächste Versuch wäre, das Zertifikat nach dem Skript noch einmal so
zu erstellen, wie es in der Doku beschrieben ist. Da steht schließlich
nichts von dem Skript …
Der übernächste Schritt wäre, die vergessene Quelle wieder rauszusuchen
und mit dem Skript zu vergleichen. Mit den Änderungen von Hand ging ja
zumindest in meiner Wahrnehmung mehr als mit dem Skript.
WSO2 ist eigentlich zu komplex und “kann” viel zu viel für das, was wir
wollen, aber ich möchte deshalb nicht z. B. Zenworks kaufen, um
“professionelle” Unterstützung zu haben.
https://www.microfocus.com/de-de/products/mobile-management/
Deshalb wäre es gut, wenn wir in linuxmuster.net einen übertragbaren Weg
dokumentieren könnten, wie man mit dieser - kostenlos verfügbaren -
Software schuleigene mobile devices managed.
Gruß Jürgen
Hi.
Das Problem an der Sache ist meiner Meinung nach, dass das ein völlig neues Feld ist, das mit dem ursprünglichen LML-Server rein gar nichts mehr zu tun hat. Natürlich betrifft das Problem zZ viele Schulen. Daher schauen sich ja auch so viele von uns nach einer gangbaren Lösung um – allerdings glaube ich im Moment nicht, dass sie WSO2 heißen wird, da das -wie gesagt- nicht auf Anhieb benutzerfreundlich geschweige denn einsetzbar war 
Ich hatte vor einiger Zeit auch von www.soti.net gehört - kostet natürlich auch, doch es gibt eine 30 Tage Trial Version und das soll angeblich plattformübergreifend laufen (was man nach allem, was ich bisher gesehen habe, von den wenigsten Lösungen behaupten kann). Wie gut oder schlecht das alles geht, kann ich nicht sagen. Mir wäre es auch am liebsten, wenn wir einfach 100 gerootete Tablets hätten, die ich komplett mit ADB und F-Droid verwalten / klonen könnte. Leider scheint es nicht soooo einfach zu sein, ein Android-Gerät wirklich dicht zu bekommen. Bei uns gehen die besagten Tablets übrigens zunächst nur in die Hände der Kollegen. Ob das nun besser oder schlechter ist, als sie direkt an Schüler zu verteilen, könnt ihr entscheiden 
Schöne Grüße,
Michael
Sehe ich anders, denn mit der “Digitalisierung” des Unterrichts werden Tablets und auch die Smartphones der SchülerInnen nicht nur aus Kostengründen eine zunehmende Rolle spielen. Wenn wir nicht die Cloud eines externen Anbieters nutzen wollen (Datenschutz!?), sollte linuxmuster.net die Cloud sein können. Nextcloud gehört z. B. aus meiner Sicht auch nicht unmittelbar zu linuxmuster. Trotzdem hat es hier Einzug gefunden, weil es im Kontext Bedarf dafür gab. Keine schöne Lösung, weil man die Geräte dazu verkabeln muss! Dies störte mich bei linuxmuster.net und linbo bei Notebooks gewaltig und mit IServ stört es mich auch noch - aber nur weil bislang wir keinen WLAN-AccessPoint haben, der die Windows Updates und die mit OPSI klaglos verkraften würde. Wenn die Geräte wireless sind, sollte auch deren Management wireless funktionieren! Im Bezug auf die Systemintegrität seh ich kaum einen Unterschied - außer dass einige KollegInnen vielleicht höhere Anforderungen an uns Medienverantwortliche als Dienstleister haben …
Ja, da hast du Recht: Tablets & eine dazugehörige Verwaltung werden kommen. Ich fände es ja auch durchaus elegant, wenn alles aus einem Guss wäre, doch MDM steht da auf einem anderen Blatt, weil das niemand als OSS anbietet. Auch bei WSO2 muss man irgendwann was dafür zahlen — vielleicht machen die es ja deswegen so kompliziert, damit Otto-Normal-Admin das nicht alleine aufsetzen kann 
Übrigens: die NextCloud App kostet zwar eine Kleinigkeit – lohnt sich aber.
Hallo,
ich bin auch nicht weiter gekommen. Wenn ich neueste Version in Docker installieren und change-ip ausführe, kann ich zwar apps anlegen beim devicemgt kann ich mich aber nicht mehr anmelden. Bekomme diesen Fehler: https://github.com/wso2/docker-iot/issues/21
und habe noch keine Lösung dafür.
Ist WSO2 eigentlich die einzige freie Lösung? Oder gibt es noch andere?
Hallo,
wollen wir wirklich aufgeben, nur weil entweder change-ip.sh nicht alle
Stellen erwischt, wo localhost ersetzt werden müsste oder das Zertifikat
nicht richtig erstellt oder der DNS nicht den FQDN nicht richtig auflöst?
Das muss doch in den Griff zu bekommen sein!
Im Moment ist die Zeit etwas knapp, aber ab dem 15.6. würde ich weiter
mit WSO2 experimentieren …
Gruß Jürgen
… also wie ich uns hier so kenne, geben wir doch nie auf??
(Es wundert mich allerdings schon, dass eine so elementare Sache nicht noch am gleichen Tag behoben wird. Das Programm ist so ja vollkommen unbrauchbar )
Hi.
Ich greife auch diesen Thread nochmal auf. Wenn Version 2.2 im docker-Container laufen sollte (und das tut es offenbar ja auch wesentlich schneller als Version 3.3.0!) und man zusätzlich die IP so umbiegen kann, dass sie im lokalen Netz und nicht über die docker-bridge kommt, müsste alles so sein, wie wir das haben wollen, oder?
Also konkret: docker mit dem suzel-Container und dazu das hier?
Ist vielleicht nochmal einen Versuch wert!?
@j.engeland: Jürgen, bist du in dieser Sache denn weitergekommen? Oder wird das so kompliziert, dass man’s lassen sollte?
Schöne Grüße,
Michael
Hallo Michael,
die erste Antwort von Promethean sieht für mich so aus, als ob der
Supportmitarbeiter meine Fragen nicht richtig verstanden hat. Oder ich
zu blöf gefragt habe.
Aber vielleicht hab ich auch noch nicht verstanden, in wie weit eine
Signatur des Herstellers für diese EMM Service App wirklich erforderlich
ist.
Vielleicht kann man Android ja auch anders davon überzeugen, diese zu
starten, wenn man sie einfach so kompiliert.
Ob das so kompliziert ist, dass man es lassen sollte? Wenn man eine
einfachere Alternative hätte, vielleicht ja.
Bislang scheint WSO2 EMM 2.2.0 immer noch die einfachste zumindest für
Androiden kostenlose Variante zu sein und das was für BYOD sinnvoll
wäre, geht ja damit.
Für die Promethean Geräte werde ich mir Radix ansehen, sobald sie
geliefert sind. Zu (zusätzlichen) Kosten hierfür habe ich auch noch
keine Aussage von Promethean bekommen
http://www.radix-int.com/device-management-for-promethean.html
Sieht so aus, als ob der Server bei denen läuft, was natürlich wieder
Datenschutzfragen aufwerfen würde.
Gruß Jürgen