Beiträge von dlueth

@M4tt0 in welchem MODE hast Du ihn gestartet? Und kannst Du Mal ein ls -la /sharedfolders/AppData anhängen?

Und häng an die Zeile mit der du den Container startest bitte Mal testweise "&& docker logs -f {containername}" dran ob das irgendetwas ausspuckt...

Hab gerade nochmal mein README mit den technischen Details angereichert die den Leuten mit einer GUI für Docker helfen könnten: https://github.com/dlueth/easyepg…-openmediavault

@DeBaschdi 3 getrennte Interfaces sind das, das apu 2d4 (hab mich falsch erinnert, hab d, nicht c) hat keine 4

@BJ1 ich glaube du willst gar nicht wissen, wie mein komplettes tvheadend-Setup aussieht... Da hängt z.b. noch ein rabbitmq für die verteilte Verarbeitung von Aufnahmen (comskip und filebot) dran

Zitat von M4tt0

So, wie kann ich denn jetzt die Konfiguration aus der /home/USER/easyepg Installation sicher "retten", die alten Container löschen und die neue Installationsmethode ausprobieren, ohne was kaputtzumachen?

Kopiere(!) den Inhalt einmal in das neue easyepg-Verzeichnis, passe die Rechte an und starte den Container mit eben diesem - dann wird da nichts mehr überschrieben und Config etc. bleiben erhalten

Ich muss nochmal um etwas Verständnis werben:

Im Moment ist mein Container gebaut für eine möglichst große Flexibilität, selbiges gilt für das Init-Script (das am Ende aber nur quasi Shortcuts via docker create anlegt für Dinge, die man auch via docker run machen könnte, aber eben manuell). Erfolgreich laufen tut das ganze momentan in folgenden Umgebungen:

1. Bei mir, APU 2c4 mit TVHeadend direkt auf dem Host und easyepg im docker via easyepg.run, angestossen durch einen cron auf dem Host
2. LibreElec
3. Unraid
4. Synology

Ich glaube bei 4. muss ich ein kleines Fragezeichen dran hängen, weil ich im Moment über den Status unsicher bin.

Ich glaube hier sind inkl. meiner selbst sehr viele Leute sehr hilfsbereit, und das finde ich persönlich auch toll so und möchte auch, dass das so bleibt. Trotzdem ist es so, dass einige Dinge einfach weder etwas mit dem Container, noch mit dem init-script zu tun haben sondern teilweise mit "Spezialitäten" des Host-Systems oder teilweise auch der Unkenntnis im Umgang mit Docker zu tun haben.

Daraus folgt dann ein kleiner Appell:
Setzt Euch bitte auch selber mit dem auseinander, was Ihr vorliegen habt und versucht Dinge zu verstehen, in der Tiefe. Das bringt Euch dann auch persönlich weiter und hilft langfristig.

Und trotzdem traut Euch auch weiterhin (wie bisher) zu fragen, es wird Euch - so gut es eben geht (!) - geholfen, das ist aber manchmal nicht ganz einfach, wenn man keine Ahnung vom umgebenden System und seinen Spezialitäten hat

So, gerade mal kurz für Euch zusammengeschrieben:

docker run \
  -d \
  -e MODE="admin" \
  -e USER_ID="1099" \
  -e GROUP_ID="1099" \
  -e TIMEZONE="Europe/Berlin" \
  -e FREQUENCY="0 2 * * *" \
  -e UPDATE="yes" \
  -e REPO="sunsettrack4" \
  -e BRANCH="master" \
  -v {path to socket}:/xmltv.sock \
  -v {path to store easyepg + data + configs}:/easyepg \
  -v {path to write XML-files to}:/easyepg/xml \
  --name=easyepg \
  --tmpfs /tmp \
  --tmpfs /var/[definition='1','0']log[/definition] \
  --rm \
  qoopido/easyepg.minimal:latest


MODE = run|admin|cron (optional, default run)
USER_ID (optional, default 1099)
GROUP_ID (optional, default 1099)
TIMEZONE (optional, default Europe/Berlin)
FREQUENCY (optional, default 0 2 * * *)
UPDATE (optional, default yes)
REPO = sunsettrack4|DeBaschdi (optional, default sunsettrack4)
BRANCH (optional, default master)
{path to socket} = absoluter(!) Pfad zum Socket, sofern vorhanden/gewünscht
{path to store easyepg + data + configs} = absoluter(!) Pfad zum Persistieren von easyepg, Pflicht
{path to write XML-files to} = absoluter(!) Pfad zum Persistieren der von easyepg erstellten XML-Dateien

Das mit dem extra-mounten des XML-Directories scheint zu gehen, habs gerade bei mir ausprobiert...

Es gibt eigentlich kaum unterschiede zwischen mod242's Container und meinem - ich hab halt nur PUID, PGID und TZ umbenannt. Sind das Vorgaben von OMV das die so heißen müssen evtl.?

@M4tt0 also der user mit dem du einen Container starten willst muss der Gruppe docker angehören, sonst geht das nicht... Vielleicht reicht das schon?

Und ja, das init-script versucht das Verzeichnis was Du ihm reingibst sicherheitshalber anzulegen, wenn bei dem also die Rechte nicht passen, dann geht auch das evtl. nicht.

Das Video muss ich mir in Ruhe anschauen, bin bisher nicht dazu gekommen...

Zitat von M4tt0

@dlueth: Am besten wäre es eigentlich, wenn die ganzen Konfigurationsfiles (wie Grabber-Instances, Combine-Instances, crontab, externe Scripte, etc.) auf einen, und die Output xmls auf einen anderen /sharedfolder verlinkt werden könnten, und der ganze Rest im Container "verschwindet" und upgegraded werden könnte. Dann könnte man die /config z.B. auf /sharedfolder/AppData/easyepg legen, und /xml auf /sharedfolder/AppData/tvheadend/data. Man bräuchte in TVH nur noch den internen Standardgrabber aktivieren, und die Verbindung wäre perfekt.

Ja, das wäre gut, ist aber mit der momentanen Ordnerstruktur von easyepg so nicht wirklich realisierbar. Was ich nochmal prüfen werde ist, ob man evtl. das xml-Verzeichnis extra reingeben kann. Ich bin momentan nicht ganz sicher, was Docker sagt wenn man ihm das easyepg-Verzeichnis reingibt und dann wiederum ein Unterverzeichnis von diesem nochmal extra.

Zitat von Ruschi

Ein abweichendes Verzeichnes als Default wird nicht akzeptiert. JETZT läuft das Setup durch.Das ist, sorry sorry nicht gut gelöst.. ich bin strikt dagegen daten auf der systemplatte zu platzieren. Es wäre wirklich gut wenn man das verändern könnte

Ich verstehe allerdings nicht, warum das nicht gehen sollte - solange der User der den Container startet entsprechende Rechte hat sollte das kein Problem sein... Denn das Verzeichnis wird ganz normal an den Container als Volume übergeben, wo das liegt ist komplett unerheblich. Das das Init-Script ein Verzeichnis im Home-Dir des aktuellen Users vorschlägt macht halt als Default durchaus Sinn für die unbedarften User, da dort am wenigsten Probleme zu erwarten sind.

@M4tt0 gibt es eine Anleitung mit Screenshots wie die docker GUI unter OMV aussieht, funktioniert und was sie genau kann?

Hintergrund:
Mein init-Script ist nur eine Vereinfachung. Wenn du unter OMV via GUI einen Container starten und ihm volumes und env-Variablen reingeben kannst, dann geht es natürlich auch so und völlig ohne init-Script.

Bei Bedarf würd ich die Parameter sonst Mal zusammenschreiben...

Siehe auch mein README für die shell-user:

https://github.com/dlueth/easyepg.minimal#prerequisites

@Ruschi als dockeruser per ssh anmelden, init-script neu ausführen, easyepg.admin neu starten und dann solltest du auch einen user easyepg im container haben und mit dem o.g. exec-befehl reinkommen.

Alternative ginge auch root auf dem host zum testen, dann müsstest du aber bei der o.g. Zeile von exec einfach das "-u easyepg" herausnehmen

@Ruschi Ja, und auch das docker start easyepg.admin sowie das nachfolgende docker exec wurde dann als root ausgeführt?

Ergänzung:
Der User easyepg innerhalb des Containers wird nur dann angelegt, wenn es nicht schon einen User gibt für die übergebene User-ID - das dürfte aber bei Root im host der Fall sein und würde erklären, warum das bei Dir mit dem User easyepg nicht geht.

Dazu dann nochmal generell der Hinweis:
Es ist eigentlich keine gute Idee Dinge mit Root-Rechten zu starten (also den Docker-Container auf dem Host) und es ist auch keine gute Idee Dinge in einem Docker-Container als Root laufen zu lassen. Also wenn es nicht das Host-System zwingend erfordert würde ich da echt dringend von abraten...

@Ruschi Mit welchem User hast Du das init-script aufgerufen? Dessen PGID und PUID werden im Container dann auch verwendet und auf den User easyepg innerhalb des Containers umgemapped.

Wenn sich bei Dir der User der den Container startet und der User der mit exec rein will unterscheiden dann führt das möglicherweise zu diesem Problem.

Aber mit meiner Zeile von oben?

@Ruschi das ist merkwürdig, bei mir geht das so. Im Container gibt es den User auf jeden Fall und auf dem Host muss der meines Wissens nach auch nicht existieren. Zumindest tut er das bei mir nicht.

Wie startest du denn den Container, mit der oberen Zeile von mir oder über OMV?

@Ruschi Macht doch Spaß Und ich benutz meine Container doch selber auch - via easyepg.run...

Und nochmal zur Erklärung für alle:

Die 3 Container die mein init-script anlegt sind eigentlich nur shortcuts für die Erzeugung verschiedener Parameter-Varianten des gleichen Images. Im Wesentlichen geht es dabei um den "MODE" in dem der Container läuft, denn abhängig davon in welchem Mode der Container gestartet wird verhält er sich anders:

easyepg.admin
=> Läuft quasi im idle (und tut rein gar nichts) so das man mit exec rein kann um easyepg zu konfigurieren

easyepg.run
=> Kann erst nach erstmaligem Setup von easyepg via easyepg.admin und exec gestartet werden, erstellt dann die entsprechenden XMLs und beendet sich wieder

easyepg.cron
=> Läuft dauerhaft und erstellt zum via init-script eingestellten Zeitpunkt die XMLs. Dieser container läuft den Rest der Zeit im idle. Diesen Container könnte man z.B. auch starten und vor dem ersten Durchlauf des Cronjobs mit exec reingehen und hier easyepg initial konfigurieren, bräuchte dann easyepg.admin z.B. gar nicht

Man muss die natürlich nicht nutzen sondern kann den Container auch mit den entsprechenden ENV-vars von Hand starten. Die Defaults der Parameter des init-scripts sind zur Not auch nochmal die Defaults innerhalb des Containers. Ergo sollte es nur nötig sein einzelne Parameter zu überschreiben.

Ich hab das aus dem README bewusst weggelassen, weil ich glaube das es für viele User einfach zu viel und zu komplex wäre und lieber den Weg mit den o.g. 3 Containern gewählt.

Ich ändere gleich mal mein README auf GitHub, es geht auch einfacher was das initiale Setup angeht:

docker start easyepg.admin
docker exec -ti -u easyepg -w /easyepg easyepg.admin ./epg.sh