Ich würde eher dafür plädieren, dass es per default so bleibt, und wenn man remote darauf zugreifen will, muss man es konfigurieren.
Lars
Ich würde eher dafür plädieren, dass es per default so bleibt, und wenn man remote darauf zugreifen will, muss man es konfigurieren.
Lars
OK, ziehe die Anfrage zurück.
Ich hatte auch übersehen, das ich die xineliboutput/allowed_hosts.conf eh manuell anpassen muss
Muss halt ansible wieder ran
Gruß
Frank
Ich habe vorhin die Rolle für den VDR um ein Template für die svdrphosts.conf erweitert (man kann jetzt eine Liste von Hosts bzw. Subnetzen in der Variablen vdr_svdrphosts angeben, die zusätzlich zu 127.0.0.1 in der Datei landen sollen: https://github.com/yavdr/yavdr…plates/svdrphosts.conf.j2) - mein Vorschlag wäre das für die allowed_hosts.conf für den streamdev-server und vnsiserver und die Konfigurationsdateien von xineliboutput usw. ähnlich zu lösen.
mein Vorschlag wäre das für die allowed_hosts.conf für den streamdev-server und vnsiserver und die Konfigurationsdateien von xineliboutput usw. ähnlich zu lösen.
Das würde ich ebenfalls begrüßen, es so umzusetzen. Alles was ich in eine eigene Datei packen kann vereinfacht das Installieren und lästige nach konfigurieren sowie das was man da im ersten Moment noch dazu übersieht
Ja, das hört sich für mich gut an.
vdr_svdrphosts ist dann ein Array/Liste?
Aktuell füge ich mein Netz per blockinfile ein, aber so wäre es eleganter.
- name: Find .conf files in /etc/vdr
find:
paths: /etc/vdr
patterns: '*hosts.conf'
recurse: yes
register: EtcConfList
- name: Find .conf files in /var/lib/vdr
find:
paths: /var/lib/vdr
patterns: '*hosts.conf'
recurse: yes
register: VarConfList
- name: give authorisation for local net
blockinfile:
path: "{{ item.path }}"
block: |
192.168.64.0/24 # any host on the local net
with_items:
- "{{ EtcConfList.files }}"
- "{{ VarConfList.files }}"
Alles anzeigen
Für die xineliboutput.conf muss es dann aber eine fixe IP sein, oder?
Gruß
Frank
vdr_svdrphosts ist dann ein Array/Liste?
Ja, das könnte dann z.B. so aussehen um ein Subnetz freizugeben:
Für die xineliboutput.conf muss es dann aber eine fixe IP sein, oder?
Laut der Dokumentation im Debian-Paket hat man da mehrere Möglichkeiten:
ZitatAlles anzeigen--remote=<LOCALIP>:<PORT>
Listen on <LOCALIP>:<PORT> for remote clients. If <LOCALIP> is provided,
it will bind to this address. You can completely omit <LOCALIP>
(--remote=<PORT>) to bind to all interfaces.
The default (if --remote is totally omitted) is, that the remote port 37890,
bound to all interfaces is used, but remote access is disabeld. In this
case, the remote access can be enabled/disabled in VDR's OSD settings menu.
Am sinnvollsten wäre es IMHO <LOCALIP> wegzulassen, sobald mehr als die Freigabe für localhost in der allowed_hosts.conf landen soll.
Ich nehme mal an Lars hatte Bedenken, dass hier ungewollte Services freigegeben werden.
Ich würde eher dafür plädieren, dass es per default so bleibt, und wenn man remote darauf zugreifen will, muss man es konfigurieren.
Lars
Aus dieser Sicht wäre es vielleicht besser die Option --remote in der xineliboutput.conf wegzulassen, dann kann ich den Remotezugriff über OSD aktivieren (mal abgesehen von allowed_hosts.conf).
Oder per ansible eine Variable abfragen und wenn sie existiert, den Inhalt als <LOCALIP> eintragen.
Gruß
Frank
Aus dieser Sicht wäre es vielleicht besser die Option --remote in der xineliboutput.conf wegzulassen, dann kann ich den Remotezugriff über OSD aktivieren (mal abgesehen von allowed_hosts.conf).
Das Paket im yaVDR-PPA folgt da der Vorkonfiguration des Debian-Pakets. Der Zugriff über localhost sollte IMHO immer freigegeben sein, sonst klappt das mit der Vorkonfiguration von vdr-sxfe mit dem Frontend-Skript in einer Virtualbox-VM nicht - das ins Plugin integrierte Frontend will man ja eher nicht benutzten, weil das nicht mit pulseaudio kann und immer den VDR mitreißt, wenn etwas schief geht.
Alles klar, so tief stecke ich da nicht drin.
Bleibt also nur die Variante über die ansible Variablen, vdr_svdrphosts und weitere.
Bleibt also nur die Variante über die ansible Variablen, vdr_svdrphosts und weitere.
Ja, wobei man ja eine durchaus eine einzelne Variable nutzen kann, wenn man da mit der Gießkanne drüber gehen will - ich habe das gerade mal gepushed: https://github.com/yavdr/yavdr…da1ae7073bd27f237d527ada9
Mit der Variablen vdr_allowed_hosts (das ist standardmäßig eine leere Liste) kann man das für alle Dateien ausrollen, die einen IP-basierten Zugriff verwalten, und wie im Commit beschrieben auch gezielt für einzelne Dienste/Plugins übersteuern.
Gibt es da noch weitere Plugins für die sowas hilfreich wäre?
Mit der Variablen vdr_allowed_hosts (das ist standardmäßig eine leere Liste) kann man das für alle Dateien ausrollen, die einen IP-basierten Zugriff verwalten, und wie im Commit beschrieben auch gezielt für einzelne Dienste/Plugins übersteuern.
Hört sich gut an, ich glaube nur für xineliboutput ist noch eine zusätzliche Variable notwendig.
In xineliboutput.conf soll das Interface angegeben werden auf dem gelauscht wird und in der allowed_hosts.conf sollen "externe" Adressen oder Bereiche angegeben werden.
Oder, wenn das geht: Wenn die Variable xineliboutput_allowed_hosts einen Wert hat, dann in der xineliboutput.conf keine <LOCALIP> eintragen.
Wenn xineliboutput_allowed_hosts definiert ist, kann man wohl davon ausgehen, dass Zugriff von extern gewünscht ist.
Weiter Plugins fallen mir im Moment nicht ein.
Oder, wenn das geht: Wenn die Variable xineliboutput_allowed_hosts einen Wert hat, dann in der xineliboutput.conf keine <LOCALIP> eintragen.
Das ist eigentlich fast genau das wie es aktuell umgesetzt ist - wenn xineliboutput_allowed_hosts oder vdr_allowed_hosts einen Inhalt haben (das Ergbnis landet in der Variablen allowed_hosts für den Template-Task: https://github.com/yavdr/yavdr…s/vdr/tasks/main.yml#L125), dann lässt er das 127.0.0.1 weg: https://github.com/yavdr/yavdr…xineliboutput.conf.j2#L12
Das ist eigentlich fast genau das wie es aktuell umgesetzt ist
Alles klar, ich sollte einfach alles lesen.
Sorry, bin manchmal einfach zu blöd.
seahawk1986 , habe mal getestet.
Ich habe die Variable übergeben
Die xineliboutput/allowed_hosts.conf wurde bearbeitet und das Subnetz eingetragen.
An der xineliboutput.conf hat sich nichts geändert
#
# Command line parameters for vdr-plugin-xineliboutput
#
# For more details see:
# - /usr/share/doc/vdr-plugin-xineliboutput/README.Debian
# - `vdr --help -Pxineliboutput`
# - /usr/share/doc/vdr-plugin-xineliboutput/README
#
[xineliboutput]
--local=none
--primary
--remote=127.0.0.1:37890
--truecolor
Alles anzeigen
Der Download der Channels.conf hat funktioniert.
vdr_svdrphosts:
- 192.168.64.0/24
Das sollte keine Auswirkungen auf xineliboutput haben, sondern nur auf die svdrphosts.conf - wenn müsstest du die Variable xineliboutput_allowed_hosts (oder vdr_allowed_hosts wenn du die selben Einstellungen für die svdrphosts.conf und die ganzen Plugins haben willst) setzen, damit das einen Einfluss auf die Konfiguration von xineliboutput hat.
Mit vdr_allowed_hosts hat es funktioniert.
Kaum macht man's richtig geht's.
Danke für Deine Geduld.
Ich hatte etwas Schwierigkeiten mit meinem Sundtek USB Stick.
Bei ca. jedem zweiten Neustart wurde er nicht eingebunden, weil der sundtek.service auf die Bretter gegangen ist.
● sundtek.service - Sundtek mediasrv
Loaded: loaded (/etc/systemd/system/sundtek.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2019-03-28 20:07:25 CET; 1min 19s ago
Process: 1050 ExecStart=/opt/bin/mediasrv -d --pluginpath=/opt/bin --wait-for-devices (code=exited, status=255)
Mär 28 20:07:25 vdrserver systemd[1]: Starting Sundtek mediasrv...
Mär 28 20:07:25 vdrserver systemd[1]: sundtek.service: Control process exited, code=exited status=255
Mär 28 20:07:25 vdrserver systemd[1]: sundtek.service: Failed with result 'exit-code'.
Mär 28 20:07:25 vdrserver systemd[1]: Failed to start Sundtek mediasrv.
Mär 28 20:07:25 vdrserver systemd[1]: sundtek.service: Service hold-off time over, scheduling restart.
Mär 28 20:07:25 vdrserver systemd[1]: sundtek.service: Scheduled restart job, restart counter is at 5.
Mär 28 20:07:25 vdrserver systemd[1]: Stopped Sundtek mediasrv.
Mär 28 20:07:25 vdrserver systemd[1]: sundtek.service: Start request repeated too quickly.
Mär 28 20:07:25 vdrserver systemd[1]: sundtek.service: Failed with result 'exit-code'.
Mär 28 20:07:25 vdrserver systemd[1]: Failed to start Sundtek mediasrv.
Alles anzeigen
Nach nun 5 von 5 erfolgreichen Starts, gehe ich von einer fehlerhaften udev Regel, bzw. einem Fehler im Programm /opt/bin/mediaclient aus.
Leider kann ich aktuell nicht mehr nachvollziehen wie die Regel ihren Weg auf meinen Rechner gefunden hat, habe aber das Paket dvb-driver-sundtek in Verdacht.
Die Regel sah wie folgt aus:
SUBSYSTEM=="usb", ACTION=="add", RUN+="/opt/bin/mediaclient --start=5 --systemdcheck"
Vermutlich wird --start=5 vor --systemdcheck ausgeführt und dann hat der Systemd Service ein Problem Start request repeated too quickly
Ich habe das --start=5 aus der Regel entfernt, seitdem startet der Service (5 von 5).
Heißt natürlich noch nichts. Werde es beobachten.
Hallo zusammen,
Ich bin YAVDR Fan seit der version 0.5 und vorab erstmal vielen Dank an das yavdr Team für dieses tolle System.
Am We habe ich mir die aktuelle YAVDR 0.7 installiert, läuft soweit gut, alle sender hell und kodi geht auch schon.
Allerdings habe ich folgendes Problem:
Der YAVDR lässt sich nicht runterfahren. Ich nabe einen Suchtimer gesetzt und wenn ich versuche das System runter zu fahren kommt folgende Fehlermeldung:
"RTC not writeable"
Die Hardware ist die selbe auf der Vorher ein YAVDR 0.62 lief.
Auch läßt sich der VDR nicht von meinem Tablet aus bedienen.
Schöne Grüße
Matthias
Der YAVDR lässt sich nicht runterfahren. Ich nabe einen Suchtimer gesetzt und wenn ich versuche das System runter zu fahren kommt folgende Fehlermeldung:
"RTC not writeable"
Sind die aktuellsten Pakete installiert?
Wie sehen die Rechte für den vdr-shutdown-wrapper aus?
ls -l /usr/lib/vdr/vdr-shutdown.wrapper
Auch läßt sich der VDR nicht von meinem Tablet aus bedienen.
Auf welchem Weg versuchst du den VDR über das Tablet zu bedienen?
Die rechte sehen folgendermassen aus:
-rwsr-s--- 1 root vdr 6136 Mär 19 19:58 /usr/lib/vdr/vdr-shutdown.wrapper
Ich benutze die AndroVDR app über Port 6419.
Ich habe das System am We aufgesetzt, sollte also aktuell sein, vdr 2.4.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!