[Docker] telerising.minimal

copain sieht so aus als würdest Du das sichern/wiederherstellen der settings.json mit einem anderen Benutzer und/oder anderen Rechten machen als dem, der die Binary dann letztlich ausführt. Wie startest Du denn aktuell die Binary bzw. mit welchem User? Welche "Rechte" haben die neu angelegte und die gesicherte settings.json?

Zitat von copain

dlueth armhf

Dir nochmals Respekt und vielen Dank für den unermüdlichen und schnellen Einsatz, was keineswegs selbstverständlich ist!

armhf 0.10.3 Buster läuft auf meinem System. Wie in Post #113 beschrieben, erhielt ich nach dem manuellen Rückkopieren der settings.json erneut 'Errno 13 Permission denied /etc/telerising/settings.json'. Danach habe ich mit der api wieder eine neue generiert, mit neuer uuid und leerem refresh_token.

Ich hoffe, dass das Rückkopieren künftig nach Updates mit dem Script wieder normal funktioniert. Oder habe ich allenfalls etwas übersehen und einen Fehler gemacht?

Kein Problem. Wenn es jetzt total exotische/spezielle Anforderungen wären würd ich's vermutlich ablehnen aus Zeitmangel. Aber da es um die normalen arm-binaries geht die meinerseits genau für die 32-bit RPIs gedacht waren, was ich aber nicht selbst testen kann, machts irgendwie Sinn XD

Starfoxfs nimm bitte explizit die Version die ich oben verlinkt habe. Im Repo ist doch immer noch die Bullseye-Version und um die geht es ja nicht XD

Starfoxfs kk danke - dann mach ich mich jetzt an den neuen release für die buster-version

Build bei GitHub läuft für die 0.10.3 auf Debian Buster Basis, der Build wird wohl ca. 3-4 Stunden dauern und steht dann im Docker Hub als Image und auch bei den GitHub Releases als Binary bereit. Zukünftge Builds bei Release durch easy werden dann automatisch auch mit Buster gebaut und nicht mehr Bullseye

Ja: Es scheinen viele Leute ihre RPIs nicht upzudaten und/oder von 32-bit auf 64-bit umzustellen. Daher ergibt sich das Problem, dass die von mir bereitgestellten Binaries zwar generell auf arm aka armhf laufen, aber nicht, wenn das OS noch Buster-basiert ist. Die GLIBC-Version von Buster ist "zu alt" für die builds und da leider statische Builds unter Linux eben doch nicht ganz statisch sind wird das zum Problem.

Da wir ja aber nun wissen, dass eine unter Buster gebaute Binary durchaus auch auf Bullseye läuft kann ich da ja eine Version wieder runter gehen...

Easy selbst hat das Problem jetzt wohl auch, denn sein rpi hat jetzt scheinbar auch bullseye drauf. Ergo haben es auch die Container von debaschdi

copain zukünftige automatische releases werden ab sofort immer auf Basis von Buster gebaut, für den Moment nicht mehr mit bullseye. Ich brauche dafür gar nichts zu tun das ist das schöne, wenn man den Kram via GitHub in Docker baut

0.10.4 build läuft, ETA ca 3-4h im Docker Hub und den GitHub releases. Ist dann das erste automatische Release auf Buster-Basis.

0.10.4 ist fertig gebaut

Klar, aber hat das einen speziellen Grund? Ich sehe in den Dingern irgendwie den Sinn nicht

YORKhq welchen Tag nimmst Du denn bei dem Docker-Container?