ElabNET Technik Forum

Kurze Fragestellung:
In der Anleitung app.php/kb/viewarticle?a=69 steht:

ryansch/unifi-rpi:latest für die Timberwolf Hutschienenserver 3xx, 6xx, 9xx

Den 3500er gab es zum Zeitpunkt der Anleitungserstellung noch nicht. Dieser basiert auf ARMv8 und scheint mir nicht vom ryansch-Image abgedeckt zu sein.
Frage 1: Korrekt?
Frage 2: Irgendeinen Vorschlag eines neuen Images? (z.B. https://github.com/linuxserver/docker-u ... pplication)
Frage 3 (nachträglich ergänzt): Wenn das von mir gefundene Image eine gute Lösung wäre, so scheint es mir, müssten wir die Anleitung neu aufsetzen oder erweitern. Denn in dem Image wird vorausgesetzt, dass man eine eigene MongoDB in einem eigenen Container aufsetzt. Aber da bin ich momentan noch mit überfordert.


Lange Info:
Steige aktuell um vom TWS 950Q auf TWS3500.

Ich habe versucht die Anleitung zum Umstieg auf ein anderen Wolfs-Modell peinlich genau einzuhalten. Das war alles sehr klar und deutlich beschrieben und hat tippi-toppi funktioniert - inkl Grafana-Einstellungen, 1-wire Umzug (950Q hatte drei interne Schnittstellen).

Ich habe dabei auch die neuen Sicherungsmöglichkeiten für Container-Volumens genutz und mir die Deploay-Einstellungen meiner selbstangelegten Container voher per Screenshot gesichert. Zusätzlich habe ich alle Volumes per SSH gesichert (bisher nicht gebraucht) und sogar die Konfigurationen von Nodered per JSON gesichert.

Nun schaffe ich es aber nicht, den Unifi-Controler auf dem 3500XL zu installieren.
Fehlermeldung im Portainer beim Deployment:


Ich habe es mehrfach aufs Neue genau nach Anleitung app.php/kb/viewarticle?a=69 probiert, um z.B. Kopierfehler oder falsche Portfreigaben auszuschließen.

Ich war (und bin mir noch immer) unsicher, ob die 3500XL Architektur vom ryansch/unifi-rpi:latest image abgedeckt wird und habe auch goofball222/unifi ausprobiert. Dort gab es dann andere Fehlermeldungen, aber das hatte ich auch erwartet.

Ich habe eben mal nicht nur Teile der Fehlermeldung, sondern, den gesamten Fehlertext in Anführungsstrichen in Google eingegeben und bin dann auf einen Eintrag in unserem Forum hier gestoßen: viewtopic.php?f=25&t=5083

Habe dann einfach mal das gleiche wie Olek gemacht und in den Network-Einstellungen meines Unifi-Container (auf Basis ryansch/unifi-rpi:latest) keine Angabe zu Hostname und Domain Name gemacht. Anschließend ließ sich der Container deployen und er läuft nun im Status "healthy"... aber ich komme noch nicht auf die Web-UI des Controllers. Olek hat angegeben, dass Problem in seinem Fall gelöst zu bekommen, da er im MacVLAN Netowrk das "parent = eth0" vergessen hatte. Das zumindest ist bei mir nicht der Fall.

Robosoc hat geschrieben: ↑Mi Apr 24, 2024 10:08 am Kurze Fragestellung:
In der Anleitung app.php/kb/viewarticle?a=69 steht:

ryansch/unifi-rpi:latest für die Timberwolf Hutschienenserver 3xx, 6xx, 9xx

Den 3500er gab es zum Zeitpunkt der Anleitungserstellung noch nicht. Dieser basiert auf ARMv8 und scheint mir nicht vom ryansch-Image abgedeckt zu sein.
Frage 1: Korrekt?

Nein, das geht nach wie vor. Hatte das Problem auch und hab dann einfach dieses Image wieder probiert. Aus irgendeinem Grund habe ich aktuell "ryansch/unifi-rpi:7.4.158-arm64v8" am Laufen. Probier's einfach stur nach Anleitung mit dem "latest" Image. Sollte funktionieren.

Ich glaube, das war weil ich es nicht hinbekommen habe, meinen Unifi-Switch so zu konfigurieren, dass er allen Traffic aus dem Gast-WLAN der Unifi-AP auf einen einzigen Port schickt, der direkt an die Gast-LAN-Buchse der Fritz!Box angeschlossen war. Die Hoffnung war wohl, dass eine neuere Version des Controllers das Problem, dass dann überhaupt gar nichts mehr funktionierte, lösen würde. War nicht der Fall, habe ich deshalb abgebrochen (und suche noch nach einer Lösung, wenn die jemand haben sollte).

fsl hat geschrieben: ↑Mi Apr 24, 2024 11:23 amProbier's einfach stur nach Anleitung mit dem "latest" Image. Sollte funktionieren.

Habe ich ja zig mal

Ich kann den Container erst dann installieren (anders als in den Anleitungen gezeigt), wenn ich keinen Eintrag in Network -> Domain Name hinterlege. Sobald ich da einen Eintrag hinterlege kommt der Fehler. Habe aber auch meine MacVLAN Einstellungen überprüft, finde dort den Fehler nicht, sollte da einer sein.

Im TWS ist MacVLAN aktiv.
Im Portainer ebenfalls eingerichtet - wie in der Anleitung beschrieben.

Aber bisher habe ich es noch nicht geschafft auf den Controller mit https://192.168.178.250:8443/ zuzugreifen.

Status ist übrigens nicht grün "healthy", sondern grün "running". Aber das ist ja auch in Ordnung.

Hier mal Screenshots aus der Container-Übersicht direkt nach dem "erfolgreichen" Deployment ohne Domain Name - sonst alles Original nach Anleitung:



Hier nach etwas Wartezeit:



Die IP-Adresse geht irgendwie verloren. Aber sie ist im Container noch eingetragen:


Wenn ich aber den Container aus dem MacVLAN-Netz entfernen will (roter Button aus dem vorherigen Screenshot, kommt folgende Fehlernachricht:


Aber mit der Zeit ist auch der Netzwerk-Eintrag in der Container-Ansicht leerer:

Und noch eine Sache die mir auffällt. Obwohl der Container im Status "running" ist (grün), schreibt der Log permanent Fehler:

Loading /usr/lib/unifi/data/system_env,
[0.020s][warning][os,thread] Failed to start thread "GC Thread#0" - pthread_create failed (EPERM) for attributes: stacksize: 2040k, guardsize: 4k, detached.,
#,
# There is insufficient memory for the Java Runtime Environment to continue.,
# Cannot create worker GC thread. Out of system resources.,
# An error report file with more information is saved as:,
# /usr/lib/unifi/logs/hs_err_pid6.log,

Ah, Moment. Probiere doch mal spezifisch das Image, das ich zitiert habe. Vielleicht ist im "latest" etwas drin, was nicht mehr funktioniert. Mir Dämmert da so dunkel etwas, dass ich das auch erst hatte und dann irgendwas mit JRE errors hatte.

Das mit dem Eintrag für "domain name" kann ich jetzt nicht mehr nachvollziehen. Zeigt mir jedenfalls nichts an, wenn ich auf die "container details" gehe.

fsl hat geschrieben: ↑Mi Apr 24, 2024 1:03 pm Das mit dem Eintrag für "domain name" kann ich jetzt nicht mehr nachvollziehen. Zeigt mir jedenfalls nichts an, wenn ich auf die "container details" gehe.

Du betreibst ihn auch im MacVLAN Modus, oder? Im Bridge ging es bei mir nicht, Port 8080 scheint bereits von einem anderen Container genutzt zu werden.

Ich habe auch vor dem Servertausch MacVLan aktiv gehabt, ist so ja auch in der Anleitung vorbereitet.

Ja, geht über macvlan.

@fsl : Hast Du wirklich alle 3 Volumes so eingetragen, wie in der oben von mir verlinkten Knowledge-Base-Anleitung beschrieben?

Ich habe es jetzt geschaft eine völlig neue Installation (neues Volume, neu aufgesetzter Container) soweit zu bringen, dass ich eine Webseite erreiche.
Das habe ich aber nicht mit den drei Volume-Settings geschaft (da hatte ich immer Fehler im Log), sondern mit den von RyanSch in seiner Wiki (https://github.com/ryansch/docker-unifi-rpi/wiki) beschriebenen:

- config:/var/lib/unifi
- log:/usr/lib/unifi/logs
- log2:/var/log/unifi
- run:/usr/lib/unifi/run
- run2:/run/unifi
- work:/usr/lib/unifi/work

Auch habe ich jetzt die aktuellen Port-Freigabe von RyanSch verwendet, also z.B. keinen 10001 mehr, dafür aber einen 8880.
Bei diesem erfolgreichen Versuch habe ich "ryansch/unifi-rpi:7.5.187-arm64v8" verwendet (die letzte 7.5er).

Ich habe nur leider noch keine Idee, wie ich das ganze jetzt auf Basis meines existierenden Volumes aufsetzen soll, dass ich aus der Migration-Datensicherung des TWS-Umzugs habe bzw. auss meiner eigenen SSH Sicherung. Wahrscheinlich muss ich einmal in den sauren Apfel beissen und alles neu machen. Aber für die Community wäre es interessant, ob wir für die 3500er Serie die Anleitung umschreiben müssen.

Ich probiere es jetzt erstmal erneut mit ryansch/unifi-rpi:latest (also aktuell der 8.0.7 und ohne Angabe von ARM64v8) aus. Mal sehen, wie weit ich damit komme. Ziel: Wenn schon neu, dann richtig.