[Docker] telerising.minimal

appleshooter

Diese Release Funktion gefällt mir, damit werde ich in Zukunft arbeiten
Nicht mehr wie bisher.

copain

Wie erwähnt, stelle ich ein kurzes Bash Script zur Verfügung. Es prüft, ob die neuste Version im Unterordner von /home/user bereits heruntergeladen (und somit installiert) wurde. Damit könnte man z. B. einen täglichen Cronjob einrichten (von mir nicht getestet). Falls bereits eine neuere Version existiert, würde sie dann automatisch installiert.

Das Löschen der alten Versionen-Unterordner in /home/user ist NICHT enthalten und müsste manuell erfolgen.

Es ist weiterentwickelt aus dem Script von Starfoxfs (Credits und Besten Dank) in Post #55 weiter oben.

Einsatz auf eigene Gefahr, aber gerne offen für Korrekturen oder Verbesserungen!

ACHTUNG: NICHT für Docker Version, sondern für .deb Binaries aus Github Repo von appleshooter!!!

Erstellen mit:

sudo nano install.sh im Homeverzeichnis /home/user

Ausführen mit:

bash install.sh

Bash

#!/bin/bash


#Wichtig dieses Script muss im Homeverzeichnis des Users ausgeführt werden wegen den Berechtigungen!


#Weiterentwickelt aus Bash Script von @Starfoxfs - Besten Dank
#https://www.kodinerds.net/thread/76211-docker-telerising-minimal/?postID=710531#post710531


DDIR="/home/user/" #Homeverzeichnis bitte anpassen
FILE="telerising_armhf.deb" #Name der Datei zum Downloaden bitte anpassen
WDIR="/etc/telerising/" #Installationsverzeichnis für Telerising bitte anpassen


LATESTVER=$(curl --silent -qI https://github.com/applesh00ter/telerising-api/releases/latest | awk -F '/' '/^location/ {print  substr($NF, 1, length($NF)-1)}'); \
DOWNLOADURL="https://github.com/applesh00ter/telerising-api/releases/download/$LATESTVER/$FILE"
VDIR="$DDIR$LATESTVER/" #Versions-Unterverzeichnis im Homeverzeichnis


SETTINGS="settings.json"




echo "##### Prüfe auf Download (und Installation) von Telerising #####"
if ! [ -e "$VDIR$FILE" ]
then
echo -e ">>> Download der Telerising Version $LATESTVER/$FILE <<< \n"
sudo mkdir "$VDIR"
wget -q -O "$VDIR$FILE" "$DOWNLOADURL"


echo "##### Prüfe auf Update oder Neuinstallation von Telerising #####"
if (find / type -d -name "telerising" 2>&1 | grep -v find)
then
echo "### Telerising Installation gefunden, führe Update aus ###"


#Update


echo -e "Stoppe Telerising.service \n"
sudo systemctl stop telerising.service
sleep 1


echo -e "Entferne ALTES Telerising Paket \n"
sudo apt purge -y telerising
sleep 1


echo -e "Installiere NEUES Telerising Paket \n"
sudo mkdir "$WDIR"
sudo apt install -y "$VDIR$FILE"
sleep 1


echo -e "Aktiviere und Starte Telerising.service \n"
sudo systemctl enable telerising.service
sudo systemctl start telerising.service
sleep 1


echo "Update abgeschlossen"


#Neuinstallation


else
echo "### Keine Telerising Installation gefunden, starte Neuinstallation ###"


echo -e "Installiere Telerising ... \n"
sudo mkdir "$WDIR"
sudo apt install -y "$VDIR$FILE"
sleep 1


echo -e "Aktiviere und Starte Telerising.service \n"
sudo systemctl enable telerising.service
sudo systemctl start telerising.service
sleep 1


echo "Neuinstallation abgeschlossen"
fi


#Latest Version bereits heruntergeladen


else
echo "### Telerising Version $LATESTVER/$FILE bereits heruntergeladen (und installiert) ###"


echo -e "Restart Telerising.service \n"
sudo systemctl restart telerising.service
sleep 1


echo "Prüfung auf Download abgeschlossen"
fi

Alles anzeigen

dlueth

Nur mal so am Rande: Sollten nicht meine arm-Binaries (also nicht die arm64) eigentlich auf dem RPI laufen?

Starfoxfs

Weis net sind das armhf 32bit ? der RPI läuft mit Debian 11 armhf Architecture.

armhf (arm hard float) ist der Debian Port für ARM Prozessoren.

RPI 32bit Raspian OS = armhf

RPI 64bit Raspian OS = arm64 und sporadisch auch armhf

Hier sieht man es genau:

Debian -- Portierungen

copain

dlueth siehe Post #91weiter oben.

Mein RPi 3B hat ein 64-bit SoC. Im Moment läuft allerdings noch ein 32-bit DietPi mit Python 3.7.3.

Deine arm.tar.gz 32-bit Binary liess sich zwar installieren aber startete leider auf meinem RPi nicht. Offenbar benötigt sie GLIBC 2.29 oder 2.30, was auf Python 3.7 nur in tieferer Version installiert ist. Du kompilierst ja bereits mit Python 3.9 oder 3.10.

Systemmässig kenne ich mich zu wenig aus und kann den Fehler nicht beurteilen. Weisst Du genaueres?

Ich wäre gerne bereit, Deine 32-bit Binary zu testen, falls sich der Fehler lösen lässt.

dlueth

armhf sollte arm/v7 sein, zu 100% so weit ich das in Erfahrung bringen konnte. Sollte also laufen. Die Binaries benötigen zur Laufzeit eigentlich kein Python auf dem Zielsystem, glibc wohl aber schon.

copain dein System ist aber schon aktuell gehalten was die packages angeht, oder?

dlueth

Ich muss mich korrigieren, da der docker Container ein scratch Image verwendet sollten die Binaries streng genommen überhaupt nichts zusätzlich brauchen

dlueth

So, nach erfolgreichem Testing durch Starfoxfs auf Basis von Python 3.9 gibt es jetzt im Docker Hub ein neues Latest auf dieser Basis sowie bei GitHub einen entsprechenden Release mit den Binaries dran.

Ab dem nächsten Release durch easy4me werden dann auch die automatischen Builds & Releases mit Python 3.9 erfolgen.

dlueth

0.10.3 steht seit ca 2 Stunden zur Verfügung. Ich plane mich mit copain 's Problem zu beschäftigen, denn mein arm binary war ansich für die älteren rpi gedacht. Kann ich Dich ggf. zum Testen nutzen copain ?

dlueth

copain Hast Du in etwa die folgende Version?

Debian GLIBC 2.28-10+deb10u2

Wenn Python 3.9 für die binary vs 3.7 bei Dir auf dem System nicht das Problem ist hilft es vielleicht einfach den Build in Buster anstatt Bullseye zu machen, was sehr einfach wäre.

dlueth

Wer mag kann mal die folgende arm (32 bit) binary ausprobieren die potentiell auf den RPIs dieser Welt laufen könnte die noch mit 32 bit laufen:

Download Data package from June 4th.

filetransfer.io

Starfoxfs Sollte die auf den 32 bit Systemen laufen baue ich nochmal eine explizite 64 bit Version davon für Dich zum Testen. Sollte alles laufen gehe ich zurück auf Buster als Baseimage anstelle von Bullseye

Starfoxfs

Bitte nicht die arm64 Binary aufgeben, deine brauch weniger Speicher als die von easy4me , wird dann auch dem Namen gerecht Telerising minimal

copain

dlueth armhf

Vielen Dank für Deine Bemühungen, die ich sehr schätze!

Deine Binary aus Post #111 läuft auf meinem System. Das Rückkopieren der settings.json hat allerdings nicht funktioniert. Ich musste mit der api eine neue generieren. Unterschied: NEUE uuid und refresh_token LEER ("").

GLIBC Abfrage:

ldd --version

ldd (Debian GLIBC 2.28-10+rpi1) 2.28

Es scheint, wenn Du Buster zum Generieren des Images verwendest, sollte es funktionieren.

Frage: Ist in Deinem Repo die armhf der Version 0.10.3 bereits auf Basis Buster? Falls dem so wäre, würde ich das Update mit dem Script ausführen.

Selbstverständlich stehe ich für weitere Tests gerne zur Verfügung.

dlueth

copain ne, das war jetzt erstmal nur ein schnelles Test-Build für Dich, wohl auch noch nicht mit der aktuellen Version.

Starfoxfs ne, die bleiben bestehen, so oder so. Ich müsste nur sicherstellen, dass die arm64 builds auch auf Buster Basis (anstelle von bullseye) laufen.

dlueth

copain & Starfoxfs denke morgen früh gibts 2 builds (arm64 ist schon durch, arm läuft noch) für euch zum testen mit der aktuellen telerising version. Laufen die schieb ich das ins repo und mach einen manuellen release. Ab dem nächsten Release von easy läuft's dann wieder vollautomatisch

dlueth

Zitat von copain

dlueth armhf
Vielen Dank für Deine Bemühungen, die ich sehr schätze!
Deine Binary aus Post #111 läuft auf meinem System. Das Rückkopieren der settings.json hat allerdings nicht funktioniert. Ich musste mit der api eine neue generieren. Unterschied: NEUE uuid und refresh_token LEER ("").
GLIBC Abfrage:
ldd --version
ldd (Debian GLIBC 2.28-10+rpi1) 2.28
Es scheint, wenn Du Buster zum Generieren des Images verwendest, sollte es funktionieren.
Frage: Ist in Deinem Repo die armhf der Version 0.10.3 bereits auf Basis Buster? Falls dem so wäre, würde ich das Update mit dem Script ausführen.
Selbstverständlich stehe ich für weitere Tests gerne zur Verfügung.

Alles anzeigen

was die settings.json angeht: das war wie gesagt noch eine ältere Version die ich da für Dich gebaut habe, nicht die ganz aktuelle. Generell kann das aber schon sein, weil Easy ja ein paar Sachen angepasst hatte in Sachen "ID-Generierung", wobei ich zugebenermaßen nicht genau weiß, was er da gemacht hat.

dlueth

So, wie versprochen dann einmal das arm64 binary sowie das für arm auf Basis von Buster - das ist die aktuelle Version 0.10.3. Wäre schön, wenn Ihr das nochmal testen könntet copain und Starfoxfs

Starfoxfs

Moin,

0.10.3 hab ich seit gestern abend schon drauf, läuft einwandfrei.

dlueth

Starfoxfs ja, aber das ist noch das bullseye-build. Das angehängte wäre Buster, also die vorige debian-Version

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?

Projekte:	TV-Empfang:
Smart DNS & VPN Infrastruktur Telerising Linux Installationspakete	Sky Sport & Show CH, Zattoo CH, Zattoo AT, Zattoo DE inkl. Plus Entertainment & Plus Sport

Jetzt mitmachen!