yavdr ansible

Zitat

Ich würde WLAN deaktiveren. Wozu ist das gut?

Habe ich inzwischen, ich wollte erst über Wlan gehen, aber wegen mangelnder Performance werde habe ich jetzt wieder auf "nur-kabel" umgestellt, ob das was bringt kann ich aber erst morgen testen, bin im Moment unterwegs.

Zitat

Wenn das Aufnahmeverzeichnis vom NAS gemountet wird, kann es auf dem Rechner nicht wieder so ohne weiteres per NFS exportiert werden und wenn der avahi-linker am Server eine angekündigte Freigabe nicht betreten kann, bindet er sie nicht ein.

Das Aufnahmeverzeichnis wird nicht vom NAS gemountet, es wird ein Ordner mit Namen des NAS im Aufnahmeverzeichnis per avahi-linker angelegt.

Oder verstehe ich da was falsch?

Zitat

Ja, leider, 2 Interfaces im gleichen Netzwerk. Das kann und wird Probleme machen

Hatte ich eigentlich bis jetzt noch nie Probleme mit gehabt.

Zitat von mini73

davie2000 die Interfaces haben unterschiedliche IPs, was da gleich ist, ist das Gateway.

Oh Mann, wie peinlich, sorry!

Also irgendwie stehe ich gerade auf dem Schlauch.

Nochmal zur Klarstellung:

- Ein vdr-Server (vdr) mit SAT Empfangskarte und streamdev-server-Plugin.

- Ein vdr-Client (beamerknecht) ohne Empfangskarte und streamdev-server- und streamdev-client-Plugin.

Beide über einen GBit-Switch an einer Fritzbox 7490.

Das NAS habe ich jetzt erstmal abgeklemmt.

Auf dem Server (vdr) sehe ich im Aufnahmeverzeichnis einen Ordner "Recordings on beamerknecht(nfs)".(Die Aufnahmen lassen sich ruckelfrei abspielen)

Auf dem Client (beamerknecht) sehe ich keinen Ordner "Recordings on vdr(nfs)" im OSD, aber im Terminal kann ich im Pfad "/srv/vdr/video" diesen Ordner bzw. den Link sehen. Der Link verweist auf "/media/vdr/Recordings on vdr beamerknecht", das ist wiederum ein Link der auf "/net/vdr/srv/vdr/video" zeigt.

Ich nehme an, daß das Verzeichnis "/net/vdr" vom automounter angelegt wird, denn auf dem Server(vdr) erscheint es erst, wenn man es betritt.

Das funktioniert auf dem Client(beamerknecht) nicht, dort kommt dann eine Fehlermeldung:

-bash: cd: /net/vdr: Datei oder Verzeichnis nicht gefunden

Das Deaktivieren des WLAN ändert übrigens nichts an der Tatsache, daß die Aufnahmen in Richtung "vdr -> beamerknecht" ruckeln.

Irgendwie scheint mir, das Problem liegt wohl darin, daß die Pakete 2x hin und her geschickt werden.

Ich würde den streamdev-SERVER am "beamerknecht" mal deaktivieren, vielleicht läßt sich dann, möglicherweise nach Reboot,

das Verzeichnis des vdr-Servers vom Beamerknecht direkt mounten?

Gibt es einen Kodi-Client am Beamerknecht, wenn ja, welche Verzeichnisse des VDR-Servers sieht der denn?

Zitat

Ich würde den streamdev-SERVER am "beamerknecht" mal deaktivieren

Bei dem Versuch ist mir aufgefallen, daß der gar nicht mehr aktiviert war, das Einbinden der Verzeichnisse hat ja auch eigentlich nichts mit dem streamdev-server zu tun und auch das Abspielen der Aufnahmen nicht, wenn das Verzeichnis eines vdrs per nfs eingebunden ist oder sehe ich das falsch.

Kodi gibt's, wenn ich über den Zeroconf Browser das "Recordings on vdr" Verzeichnis einbinde, bekomme ich beim Versuch es zu betreten "Couldn't connect to network server"

Im Log:

2020-06-11 13:03:01.378 T:140385728141056   ERROR: Unable to lookup host: '2003:e1:170c:3d00:226:18ff:fe1b:87a1'
2020-06-11 13:03:01.379 T:140385728141056   ERROR: GetDirectory - Error getting nfs://[2003:e1:170c:3d00:226:18ff:fe1b:87a1]:2049/srv/vdr/video/
2020-06-11 13:03:01.384 T:140386982262976   ERROR: CGUIMediaWindow::GetDirectory(nfs://[2003:e1:170c:3d00:226:18ff:fe1b:87a1]:2049/srv/vdr/video/) failed

Versuche ich es über "Network File System" gibt es einen "permission denied"-Fehler, wenn ich das Verzeichnis aufrufen will.

2020-06-11 13:06:16.682 T:140385728141056   ERROR: NFS: Failed to mount nfs share: /srv/vdr/video (mount/mnt call failed with "RPC error: Mount failed with error MNT3ERR_ACCES(13) Permission denied(13)")

Vielleicht muß der vdr User noch in irgendeiner Gruppe sein?

Ich probier nochmal was beizutragen:

Du nutzt IPv6 für VDR (wegen '2003:e1:170c:3d00:226:18ff:fe1b:87a1')?

Das würde ich probehalber mal abschalten und nur mit IPv4 arbeiten.

Ich verwende ja jetzt nicht NFS, sondern Samba, aber da gibt es zum Testen in der host_vars/localhost die Einstellung "insecure" für NFS. Bin mir jetzt nicht klar, wie das direkt einzustellen ist, ohne das ansible-playbook durchlaufen zu lassen.

Jedenfalls, wenn Kodi das nicht schafft, ist klar, daß der Client-VDR das Verzeichnis auch nicht sieht.

Sind bei beiden VDRs die IDs für den User "vdr" bzw. die Gruppe identisch?

Zitat von davie2000

Du nutzt IPv6 für VDR (wegen '2003:e1:170c:3d00:226:18ff:fe1b:87a1')?

Das würde ich probehalber mal abschalten und nur mit IPv4 arbeiten.

Mit Bewusstsein habe ich das nicht eingeschaltet, wo würde ich das denn abschalten?

Zitat von wmautner

Sind bei beiden VDRs die IDs für den User "vdr" bzw. die Gruppe identisch?

Ja, wäre das der Grund würde es ja auch in die andere Richtung nicht funktionieren.

Zitat von wmautner

aber da gibt es zum Testen in der host_vars/localhost die Einstellung "insecure" für NFS.

Soweit ich weiß ist diese Option nur dafür da um Ports oberhalb von 1024 nutzen zu können und das brauchen eigentlich nur Macs.

Zitat von wmautner

Jedenfalls, wenn Kodi das nicht schafft, ist klar, daß der Client-VDR das Verzeichnis auch nicht sieht.

Ja, mal sehen ob ich in der Richtung noch was finde.

Zitat von massi

Mit Bewusstsein habe ich das nicht eingeschaltet, wo würde ich das denn abschalten?

Auszug von hier:

The simplest way to instantly disable the IP version 6 network protocol system on on Ubuntu 18.04 is to execute the following commands:

$ sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
$ sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

Oder du trägst in die diversen "allowed_hosts.conf"-Dateien probehalber auch mal die IPv6 Adressen als erlaubt ein.

Danke, habe ich mal abgeschaltet, es ändert sich aber leider nichts.:-(

Vielleicht sollte ich den ganzen Klumpatsch einfach nochmal neu installieren.

Hmm, ich habe auch ipv6 aktiviert - und zwar, weil mein Router nur mehr eine ipv6-Adresse als Nameserver zuläßt, und ich den eigenen (inkl. Blacklists etc.) doch präferiere gegenüber dem des Providers - aber die IPs in den allowed_hosts usw. habe ich ebenfalls nur in ipv4 eingetragen, bisher kein Problem.

Aber wenn da eine verquere Konfiguration "eingebrannt" ist, müßten Sie schlimmstenfalls Server UND Client neu installieren ... das ist aber die "Windows-Lösung".

Mal eine Frage zur Ubuntu Server Version, da scheint es jetzt nur noch diese Live Installer ISOs zu geben, kann man die nehmen um ansible zu installieren?

Die Links in der ansible Doku führen leider ins Leere.

Ja, für focal kann man die Live-Installer Server ISOs nehmen, das Playbook sorgt dafür, dass cloud-init nicht stört. Die Alternate Install ISOs werden jetzt als Legacy ISOs geführt: http://cdimage.ubuntu.com/ubun…r/releases/20.04/release/

Danke!

Und gleich noch eine Frage, lassen sich über die "host_vars/localhost" Variablen der setup.conf vorbelegen, bzw. wie kann man das bewerkstelligen.

Zitat von seahawk1986

Die Alternate Install ISOs werden jetzt als Legacy ISOs geführt: http://cdimage.ubuntu.com/ubun…r/releases/20.04/release/

Habe ich vor ein paar Tagen mal getestet!

Der Installer funktioniert so wie früher und man kann problemlos den Ubuntu-Server-Focal auch nur auf eine Partition der SSD installieren, ohne das die gesamte SSD platt gemacht wird!

Außerdem wird das "cloud.init"-Zeugs gar nicht erst installiert.

Zitat von massi

Und gleich noch eine Frage, lassen sich über die "host_vars/localhost" Variablen der setup.conf vorbelegen, bzw. wie kann man das bewerkstelligen.

Bislang gibt es noch keinen Mechanismus, um eine komplette setup.conf zu kopieren. Grundsätzlich ist es kein Problem das mit dem Playbook zu erledigen (analog zu den Tasks für die channels.conf), man muss sich nur im klaren sein, dass man dadurch leicht eigene Einstellungen überschreiben kann, die man über das OSD gemacht hat (die setup.conf wird vom VDR beim ersten Stoppen nach der Installation erstellt, so dass man die setup.conf entweder vor der Installation des vdr Paket hinterlegen muss oder sie immer überschreiben lässt).

Eventuell lohnt es sich da ein Modul zum Zusammenführen der vorhandenen setup.conf mit den explizit vom Playbook zu setzenden Werten zu basteln.

Danke, ich fürchte nur, das übersteigt im Moment noch meine Fähigkeiten in Bezug auf ansible.

Ich habe jetzt nochmal komplett neu installiert, aber das Verzeichnis des anderen vdr taucht immer noch nicht auf, so wirklich verstehen tue ich den Mechanismus sowieso nicht.:-/

Ich habe jetzt nochmal versucht dem Problem des fehlenden Recording-Verzeichnisses auf den Grund zu gehen.

Das Problem scheint der automounter (autofs) zu sein.

Auf dem Server zeigt mir ein service autofs status das hier an:

● autofs.service - Automounts filesystems on demand
   Loaded: loaded (/lib/systemd/system/autofs.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-06-13 23:56:57 CEST; 32min ago
  Process: 2489 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /var/run/autofs.pid (code=exited, status=0/SUCCESS)
 Main PID: 2503 (automount)
    Tasks: 4 (limit: 4638)
   CGroup: /system.slice/autofs.service
           └─2503 /usr/sbin/automount --pid-file /var/run/autofs.pid

Jun 13 23:56:57 vdr systemd[1]: Starting Automounts filesystems on demand...
Jun 13 23:56:57 vdr systemd[1]: Started Automounts filesystems on demand.

Soweit alle paletti.

Auf dem Client, wo das Recording-Verzeichnis nicht eingebunden wird, wird das hier angezeigt.

● autofs.service - Automounts filesystems on demand
   Loaded: loaded (/lib/systemd/system/autofs.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-06-13 22:14:53 UTC; 15min ago
  Process: 868 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /var/run/autofs.pid (code=exited, status=0/SUCCESS)
 Main PID: 873 (automount)
    Tasks: 4 (limit: 2011)
   CGroup: /system.slice/autofs.service
           └─873 /usr/sbin/automount --pid-file /var/run/autofs.pid

Jun 13 22:14:52 beamerknecht systemd[1]: Starting Automounts filesystems on demand...
Jun 13 22:14:53 beamerknecht systemd[1]: Started Automounts filesystems on demand.
Jun 13 22:15:00 beamerknecht automount[873]: create_client: hostname lookup failed: Temporary failure in name resolution
Jun 13 22:15:00 beamerknecht automount[873]: create_client: hostname lookup failed: Temporary failure in name resolution
Jun 13 22:15:00 beamerknecht automount[873]: get_exports: lookup(hosts): exports lookup failed for vdr
Jun 13 22:15:00 beamerknecht automount[873]: key "vdr" not found in map source(s).

Ob es was mit den autofs Versionen zu tun hat?

Auf dem Server wo es funktioniert ist folgende Version:

autofs:
  Installiert:           5.1.2-2yavdr0
  Installationskandidat: 5.1.2-2yavdr0
  Versionstabelle:
 *** 5.1.2-2yavdr0 100
        100 /var/lib/dpkg/status
     5.1.2-1ubuntu3.1 500
        500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
     5.1.2-1ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Auf dem Client diese:

autofs:
  Installed: 5.1.2-1ubuntu3.1
  Candidate: 5.1.2-1ubuntu3.1
  Version table:
 *** 5.1.2-1ubuntu3.1 500
        500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     5.1.2-1ubuntu3 500
        500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Sonstige Unterschiede sehe ich nicht, die autofs Konfigurationsdateien sind identisch.

Irgendjemand eine Idee?

Beamerknecht kann anscheinend den Hostnamen 'vdr' nicht auflösen.

Viell. hats bei dir auch was an der resolv.conf - siehe hier. Glaub ich aber eher nicht.