VDR Portal

Hallo zusammen,

ich habe schon seit einiger Zeit das Problem, dass sich vdradmin-am nicht mehr mit meinem VDR verbinden kann.
Zuerst musste ich feststellen, dass meine VDR-Installation zu neu ist (e-tobi repository) und daher den Port 6419 nutzt usw.
Lange Rede, kurzer Sinn: Es stellte sich heraus, dass ich nicht einmal per telnet auf VDR zugreifen kann. Ich kreige nur diese Meldung:

Server:~# telnet localhost 6419
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Access denied!
Connection closed by foreign host.

In der /var/log/syslog erscheint lediglich der Eintrag:

Jun 4 17:24:25 Server vdr: [4008] connect from 127.0.0.1, port 44302 - DENIED

Dabei wechselt der Port mit jedem Versuch.

Meine svdrphosts.conf ist allerdings richtig konfiguriert, also 127.0.0.1 eingetragen (siehe Anhang).

Hoffentlich könnt Ihr mir helfen, langsam bin ich echt am verzweifeln.

Grüße,
Diewi

Danke für deine schnelle Antwort.Meinst du den Rechnernamen in /etc/hosts? Nein, den habe ich seit der Installation nicht geändert.
Hier wäre meine /etc/hosts:


127.0.0.1 localhost
127.0.1.1 Server.fritz.box Server

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts


Die zweite Zeile mit dem Eintrag 127.0.1.1 erscheint mir doch etwas komisch, mein Gentoo habe ich etwas anders konfiguriert. Da werde ich mal ein wenig herumprobieren.

Wenn ich ein telnet auf "Server.fritz.box" durchführe bekomme ich folgende Meldung (svdrphosts.conf vorher angepasst, 0.0.0.0/0 erlaubt):


Server:~# telnet Server.fritz.box 6419
Trying 127.0.1.1...
telnet: Unable to connect to remote host: Connection refused

Merkwürdig.

Vielen Dank für deine Ideen, FireFly.

Ich habe noch die ersten beiden Zeilen auf "127.0.0.1 Server.fritz.box Server localhost" geändert, hat aber erwartungsgemäß nichts gebracht.

Ein Eintrag mit der eth0-IP würde bei mir wohl nichts bringen, da ich nur lokal auf dem Rechner arbeite. Ich habe mich per ssh eingeloggt und versuche dann eine telnet-Verbindung zum VDR aufzubauen. Aber ich habe auch den Ansatz mit "192.168.178.x Server.Home" ausprobiert. Geholfen hat's leider nichts. Komischerweise kann ich nicht von außen auf den VDR zugreifen (also mittels "telnet 192.168.178.x 6419" mit einem anderen Rechner). Dann heißt es nur "Connection refused".
Bevor hier ein falscher Verdacht aufkommt; die IPTables sind leer.

Gute Idee, schmirl. Die Datei liegt in /var/lib/vdr/. Die Zugriffsrechte habe ich noch nicht überprüft, werde ich aber machen, sobald ich wieder zuhause bin.

[UPDATE]
Dein Hinweis ist wohl genau der richtige. Das Verzeichnis /var/lib/vdr enthält fast nur symlinks auf /etc/vdr/*. Die Rechte dort sind "rw-r-r" für den Benutzer vdr und die Gruppe vdr. Scheint mir richtig zu sein, ist es aber wohl nicht. Ich habe nämlich den vdr nun mal ohne die Option "-u vdr" gestartet, also mit root-Rechten und promt erscheint die Zeile "loading svdrphosts.conf". Ich werde das jetzt weiter untersuchen mich mit der Lösung melden, wenn ich sie gefunden habe.

Vielen Dank an alle die mir hier geholfen haben.

[/UPDATE]

So, Problem gelöst.

Wie zuvor gesagt, kann der VDR die Datei /var/lib/vdr/svdrphosts.conf einlesen, wenn er mit root-Rechten gestartet wurde. Jetzt habe ich den symlink aus /var/lib/vdr durch die eigentliche Datei /etc/vdr/svdrphosts.conf (Dorthin zeigte der symlink) ersetzt. Nun nimmt mein VDR auch mit der Option "-u vdr" Kommandos mittels SVDRP entgegen.
Ich nehme an, dass der VDR darüber stolpert, dass die symlinks, anders als die eigentliche Datei, "volle" Rechte haben und dadurch beim einlesen stolpert.

Nochmals Vielen Dank.

Grüße,
Diewi

So, jetzt habe ich noch ein paar Tests gemacht. Es lag definitiv am Symlink und nichts anderem. Vielleicht hilft's noch wem, da ich vor einiger Zeit schon mal gelesen hatte, dass ein E-tobi-VDR-Nutzer das gleiche Problem hatte, um dann wieder auf die c't-Version zu wechseln.

Folgende Schritte:

- "ls -l /etc/vdr/" --> Ausgabe (gekürzt): "-rw-r--r-- 1 vdr vdr 441 5. Jun 11:41 svdrphosts.conf"
- "rm /var/lib/vdr/svdrphosts.conf"
- "ln -s /etc/vdr/svdrphosts.conf /var/lib/vdr/svdrphosts.conf"
- "/etc/init.d/vdr restart"
- "less /var/log/syslog" --> loading svdrphosts.conf fehlt: Jun 7 17:40:31 Server vdr: [2156] loading /var/lib/vdr/reccmds.conf
Jun 7 17:40:31 Server vdr: [2156] loading /var/lib/vdr/remote.conf

- "rm /var/lib/vdr/svdrphosts.conf"

- "cp /etc/vdr/svdrphosts.conf /var/lib/vdr/"
- "/etc/init.d/vdr restart"

- "less /var/log/syslog" --> loading svdrphosts.conf vorhanden: Jun 7 17:43:54 Server vdr: [2295] loading /var/lib/vdr/reccmds.conf
Jun 7 17:43:54 Server vdr: [2295] loading /var/lib/vdr/svdrphosts.conf
Jun 7 17:43:54 Server vdr: [2295] loading /var/lib/vdr/remote.conf


Nur, um das klar zu stellen, mir geht es hier nicht um Rechthaberei, sondern ich finde den Fehler einfach nur so verzwickt, dass ich noch einmal explizit darauf hinweisen wollte.
Hervorgerufen wird dieses Verhalten wohl durch eine wie auch immer geartete Abfrage über die Rechte oder den Typ der zu öffnenden Datei (Sicherheit!). Bei den elementaren Dateioperationen kann ich schon vorstellen, dass der Link dann nicht aufgelöst wird, sondern dessen Rechte zurückgegeben werden. Ich meine mich erinnern zu können, dass ich vor 4 oder 5 Jahren einen ähnlichen Fehler bei einem anderen Programm hatte, der auch nur durch einen Symlink hervorgerufen wurde.

@schmirl: Natürlich liegt es nahe, dass der Fehler hier eher beim Benutzer zu suchen wäre (eine Zeile verrutscht etc.). Das trifft bei so etwas wohl auch auf 99% der Fälle zu (Hätte ich wohl auch vermutet). Hier haben wir wohl eine der wenigen Ausnahmen.

Viele Grüße,
Diewi