[vdr] Announce: videgor-0.0.4

Zitat

Original von clausmuus
Ne andere Frage die sich mir nun stellt ist, wie ich die IP-Adresse herausbekomme die mein PC nach ausserhalb des lokalen netzwerkes hat. Oder besser gesagt mein Router? Wie kann ich die abfragen, und könnte das nicht das dvdr-vidtrans-Plugin selbst in erfahrung bringen?

Dazu musst Du im Webinterface des Routers die Status-Seite befragen. Für meinen WRT54GS tut es folgender Schnippsel:

vdr:~# cat getwanip
#! /bin/sh
cd ~
wget "http://benutzername:passwort@192.168.1.1/Status_Router.asp"
WANIP=`grep "var wan_ip" /root/Status_Router.asp|cut -f2 -d"="|cut -f1 -d";"`
echo $WANIP
rm /root/Status_Router.asp

Jetzt brauch ich nur noch jemanden, der mir die Ausgabe "84.130.xxx.xxx" um die Anführungszeichen kürzt.

Die IP wird in der setup.conf gespeichert als dvdrvidtrans.transport = tcp://84.130.xxx.xxx:11073

Mittels sed kann man die ermittelte WAN-IP dann (vor dem Start von VDR natürlich) in die setup.conf übertragen:

sed -i "s/^dvdrvidtrans.transport.*/dvdrvidtrans.transport= tcp://$WANIP:11073/" /usr/local/vdr/etc/setup.conf

Zitat

Ne andere Frage die sich mir nun stellt ist, wie ich die IP-Adresse herausbekomme die mein PC nach ausserhalb des lokalen netzwerkes hat

www.ipnummer.de

Gruß bacman

Zitat

Original von clausmuus
Hi,

...

Ne andere Frage die sich mir nun stellt ist, wie ich die IP-Adresse herausbekomme die mein PC nach ausserhalb des lokalen netzwerkes hat. Oder besser gesagt mein Router? Wie kann ich die abfragen, und könnte das nicht das dvdr-vidtrans-Plugin selbst in erfahrung bringen? Und wie Update ich diese Information ohne den VDR neu zu starten?

Claus

Alles anzeigen

Hi,
ne andere Alternative wäre ne Dyndns Zuordnung, dann könnteste mit nem einfachen nslookup/host bequem deine Externe IP abfragen.

Noch besser wäre es den Dyndns Namen in der Setup.conf anstelle der IP zu benutzen...

Gruß Christian

Hi All,

danke für die Antworten. Die sache mit dem dyndns find ich am besten. Hätte auch selber drauf kommen können, wo ich doch sowieso nen dyndns namen habe
Allgemein verwendbarer ist natürlich www.ipnummer.de, vor allem in betracht dadrauf, das ich das ja in der MLD integrieren will, und das so bei jedem funktionieren wird.

Claus

Tach,

bevor ich mir dieses recht interessante Projekt einmal ansehe, habe ich doch zunächst mal ein paar Fragen hierzu.

Ungeachtet der rechtlichen Seite, wie sieht es da mit der Sicherheit aus ?

Ich unterstelle sicherlich keinem User, irgendwelche Angriffe auf meine Festplatten zu starten, die Community an sich hier hatte ich die ganze Zeit stets den Eindruck, besteht aus ehrlichen, netten Menschen (sieht man mal so von Ausrutschern wie Morone ab...hehe... Freundschaft, Stefan !), aber wenn bspw. ein VDR unter Root läuft, wie wird bei dieser Geschichte verhindert, dass Leute Zugriff auf's System bekommen ?

Nehmen wir einmal an, natürlich rein hypothetisch, ich hätte irgendwelche Softpornos von mir und meiner (nichtexistentin) Freundin oder sonstwie irgendwelches Sex-, Hardcore-, Crime- oder Action-Material, dass auf anderen Festplatten nichts zu suchen hat. Wie verhindere ich hier, dass andere User an diese Aufnahmen herankommen ?!

Kann man also bestimmte Festplattenbereiche komplett sperren bzw. wie kann man es ermöglichen, dass Aufnahmen in Teil- oder Komplettbereichen für das Peer-To-Peer-Netzwerk unzugänglich gemacht werden ?

Ferner, wenn wir schon dabei sind, Aufnahmen zu tauschen, wieso beschränkt sich das nur auf .vdr-Daten ? Letztendlich sind diese Dateien ja doch recht gross und wenn man bspw. Konvertierungen nach .avi, .ogg, .mpg oder anderen Containerdateiformaten macht, die einem nicht sooo viel Platz auf der Platte klauen, dann sollte man es doch möglich machen, auch an diese Daten heranzukommen, sofern der User sie den Mitusern zur Verfügung stellen will.

Wie wird der Zugriff anderer, sensibler, persönlicher Dateien verhindert (Adressbücher, Mails, sonstiger Privat"scheiss") ?

Ich bin zwar kein Hochsicherheitsfanatiker, hab's aber nicht wirklich gern, wenn durch Sicherheitslücken irgendwie andere Leute auf meinem Rechner stöbern können.

Ein letztes bezieht sich auf die Installationsroutine, in der von irgendwelchen Patches die Rede ist, die es da aufzuspielen gilt. Jetzt ist ja bspw. der Bigpatch zu einer aktuellen Institution geworden, die man nicht mehr missen möchte. Ist dieser "compliant" verträglich mit dem Bigpatch ? Derzeit für VDR 1.3.37.

Greets Olaf

Hi olafhenkel,

also ich für meinen Teil werde dieses Plugin nur auf nem Rechner laufen lassen auf dem sich lediglich der VDR und dessen Aufnahmen befindet. Das verhindert dann zwar noch immer nicht das ein eventueller Angreifer auf zugriff auf mein internes Netzwerk erhält, aber da ich lediglich unter Linux arbeite, habe ich da keine all zu grossen Bedenken. Alternativ würde sich noch anbieten wirklich nur mit Nachbern oder Freunden zu scharen...

Was die Patches betrifft. Ich konnte die problemlos nach dem BigPatch einspielen. Lediglich ein einfach aufzulösender Rejekt. Wobei mir das allerdings auch nicht besonders weiterhalf, da ich ja wie bereits geschrieben, wie andere auch lediglich nen Absturtz produzieren konnte

Claus

Hi
ich habe auch die undefined symbol-probleme (verschiedene - je nachdem welches der 3 plugins ich aktiviere).
Gibt es dafür eine Lösung?
Ich habe gerade eine make clean und make plugins clean gemacht und jag den kompletten kram nochmal durch - vielleicht hilfts...

Beim Igor selbst habe ich auch "probleme": wenn ich igor aufrufe passiert *nichts*. Beim compilieren selbst gab es keine Fehlermeldungen.

"igor --help" geht zwar
bei
igor --netport 11073 --clientport 11072 --boot vdr.ira.uka.de:11073
kommt direkt das kommandoprompt zurück - ohne igrgendeine info.
(okay - ich habe die ports noch nicht weitergeleitet - aber wenn es daran liegt sollte es doch zumindest eine meldung wert sein, oder?)

Gruß
Thorsten Gehrig

Um nochmal bißchen Schwung in die Sache zu bringen:

t2x: Bei mir sieht's genauso aus, igor beendet sich gleich wieder und das Log hilft mir genauso viel (oder so wenig) wie bei Dir.

Im Log steht ja, daß nix in der Callback-Liste (was immer das auch ist) steht und er sich deswegen gewollt) beendet, zumindest interpretiere ich das so.

Ich hab mich mal bei der Mailing-List angemeldet, vielleicht gibts da neuen Input. Hat das vielleicht schonmal jemand versucht?

Achja, wenn ich versuche, den vdr (1.3.34) mit den Plugins zu starten, gibts bloß ne endlose Schleife, wo der vdr sich dauernd neu startet. Nehm ich die Plugins wieder raus, dann läuft der vdr wieder. Aber das hab ich mal hintenangestellt, weil igor ja bis jetzt noch nicht tut.

Grüße,
beemer

Hmm, Kendy hat mir am 27.12. geschrieben, dass er "heute oder morgen" noch 0.0.5 mit einem Fix für mein Problem veröffentlichen wollte. Leider ist bisher aber nix passiert.

Naja, immerhin funktioniert der Server wohl jetzt wieder... konnte gestern mit igor noch keine Verbindung herstellen, aber jetzt funktionierts wohl.

igor beeendet sich nicht mehr sofort, sondern bringt hübsch viele Einträge im Log:

1136369959.588908 NODE5:got a message of type RecommendLinks
1136369959.651171 NODE5:got a message of type WantNewLinks
1136369959.754321 NODE5:got a message of type RecommendLinks
1136369959.878680 NODE5:got a message of type WantNewLinks
1136369960.490576 NODE5:got a message of type Ping
1136369960.593215 NODE5:got a message of type WantNewLinks
1136369961.038454 NODE5:got a message of type Ping
1136369961.140067 NODE5:got a message of type RecommendLinks
1136369961.384606 NODE5:got a message of type WantNewLinks
1136369961.732813 NODE5:got a message of type RecommendLinks

Na, dann werd ich wohl mal den Compiler anwerfen und schauen, ob ich den vdr mit den igor-Plugins zum Laufen bekomme...

Grüße,
beemer

Kommando zurück, was den Server angeht... nachdem ich jetzt alle Plugins für den igor compiliert hab, kriegt igor wieder keine Verbindung zum Server... grrr!
Wie soll man denn da was ausprobieren?

Wie auch immer, der vdr kommt nur bis zum Starten des dvdrepg-Plugins und dann werden kommentarlos die dvb-Treiber entladen... vdr-Neustart eben. Mal sehen, ob ich über mehr Debug-Output des vdrs was rauskriege...

Grüße,
beemer

Gibt's den Server denn nicht als Paket zum selber installieren? Wehre ja auch interessant wenn man den nur in der eigenen Famile oder mit ausgesuchten Nachbern benutzen möchte...

--- edit ---
Ich hab noch mal eben scnlell nachgelesen. Mit dem Komando 'igor' lässt sich nen eigener igor Server starten. An diesen müsste man dann die Klients koppeln. Den Server kann man auch mit nem externen Server verbinden.
--- edit ---

Claus

clausmuus: Wo hast Du denn das nachlesen können?

Vielleicht bringt mich das ja etwas weiter. Das Hochdrehen des Loglevels im vdr hat leider keine erhellenden Erkenntnisse gebracht. Wie gehabt gehts nach dem Starten des dvdrepg-Plugins in den Keller... zum Neustarten!

Jan  4 15:45:55 viac3 vdr[27116]: starting plugin: dvdrsched
Jan  4 15:45:55 viac3 vdr[27116]: starting plugin: dvdrepg
Jan  4 15:45:59 viac3 kernel: saa7146: unregister extension 'dvb'.
Jan  4 15:45:59 viac3 kernel: saa7146: unregister extension 'budget_ci dvb'.

Grüße,
beemer

Hi beemer,

auf der igor-Website unter dem Punkt Installation.

Claus

Hi clausmuus,

dann hab ich da offenbar was falsch verstanden... ich bin bisher immer davon ausgegangen, daß man igor mit den aufgeführten Parametern starten muß und dann den vdr mit den drei Plugins. Über das export-Statement teilt man dann dem vdr mit, wo der igor-daemon zu erreichen ist.

Wenn Du recht hast, müßte ich ja den igor-daemon auch einfach so starten können ohne den Verweis auf einen anderen Server per --boot. Das funktioniert bei mir aber leider nicht, der igor-daemon beendet sich wie gehabt sofort wieder.

Aber irgendwie muß es doch gelingen, einen "Ur"-Igor zu starten. Das wäre zum Ausprobieren und für lokale, vertrauenswürdige Netzwerke sehr praktisch. Zum einen weiß man dann, daß der daemon läuft und erreichbar ist und man braucht sich nicht so viel um die Sicherheit zu sorgen.

Grüße,
beemer

Also soweit ich das verstanden habe, braucht man keinen anderen igor Server angeben. Ich kann das aber erst heute abend selber ausprobieren. Bisher hatte ich gar keinen igor gestartet, sondern immer versucht vdr direkt mit dem Zentralen Igor zu verbinden...

Claus

auch bei mir lässt sich igor nicht starten, bzw. beendet sich sofort wieder ohne irgend einen Hinweis darauf was da falsch läuft

Claus

Inzwischen hab ich einiges gelernt, u. a. durch eine Antwort von Kendy Kutzner von der dvdr-Mailinglist.
Hast Du den igor-daemon mit folgender Befehlszeile gestartet?

igor --netport 11073 --clientport 11072 --boot vdr.ira.uka.de:11073

Damit bekomme ich auch nur ein kurzzeitiges Verschwinden des Prompts hin und der igor-daemon beendet sich sofort wieder. Schau mal in der igor.log nach, was da geschrieben wird. Die igor.log wird in dem Verzeichnis abgelegt, von dem aus Du igor gestartet hast.
Bei mir sieht das mit obiger Befehlszeile so aus:

1136330480.052446 NODE5:node_init
1136330480.053526 CONN5:connection with fd 4 changed state from EMPTY to LISTEN
1136330480.069933 CONN5:connection with fd 5 changed state from EMPTY to LISTEN
1136330480.104520 NODE5:bootstrap in progress
1136330481.722987 CONN5:connection with fd 6 changed state from EMPTY to OPENING
1136330481.753333 NODE5:node_init_done; ref: (d7076b5be5d8d0caf651b6be71991da6986d6b59 viac3.anlagen.local:11073), net_listen: viac3.anlagen.local:11073, client_listen: viac3.anlagen.local:11072
1136330481.753538 DFLT5:back to main, starting main loop
1136330481.793615 NODE3:no connection left, exiting now
1136330481.793644 NODE5:shutting down node
1136330481.793667 NODE5:dumping connection table
1136330481.793735 NODE5:conntable: otherend (--EMPTY-ID-- --EMPTY-TRANSPORT--), connstate OPENING, fd 6
1136330481.793745 NODE5:dumping connection table finished
1136330481.793810 CONN5:connection with fd 4 changed state from LISTEN to CLOSED
1136330481.793820 CONN5:the just closed connection (fd 4) sent 0 bytes in 0 messages and received 0 bytes in 0 messages. 0/0 bytes are left for recv/send
1136330481.793854 CONN5:connection with fd 5 changed state from LISTEN to CLOSED
1136330481.793900 CONN5:the just closed connection (fd 5) sent 0 bytes in 0 messages and received 0 bytes in 0 messages. 0/0 bytes are left for recv/send
1136330481.793921 NODE5:closing connection with cbhandle 3 and wcbhandle 0
1136330481.793943 CONN5:connection with fd 6 changed state from OPENING to CLOSED
1136330481.793952 CONN5:the just closed connection (fd 6) sent 0 bytes in 0 messages and received 0 bytes in 0 messages. 0/0 bytes are left for recv/send
1136330481.793991 NODE5:node shutdown complete
1136330481.793999 NODE5:NODE stat: Sent 0 bytes in 0 messages; Received 0 bytes in 0 messages; Used 1 connections
1136330481.794012  CBL3:nothing found in callbacklist, returning 0
1136330481.794024  CBL5:CBL statistics: average fds found 1.500000, average timers found 1.500000, average mintimer val 0.040114

Übersetzt heißt das, daß eine Verbindung zustande gekommen ist (node_init_done, ID wurde generiert). Dann wird der daemon aber beendet, da keine Verbindungen übrig sind (no connection left, exiting now).

Sollte die Zeile mit dem node_init_done so aussehen:

1136390534.283624 NODE5:node_init_done; ref: (--EMPTY-ID-- viac3.anlagen.local:11073), net_listen: viac3.anlagen.local:11073, client_listen: viac3.anlagen.local:11072

Dann bekommt der igor tatsächlich keine Verbindung, was durch den Eintrag --EMPTY-ID angezeigt wird.

Ich habe dann in der Mailinglist folgende Hinweise gefunden. Man nehme eine igor.conf mit folgendem Inhalt:

cont_if_no_conns: 1
bootstrap: vdr.ira.uka.de:11073
netport: 11073
clientport: 11072

Dann starte den igor mit

igor -c /pfad/zu/igor.conf

Dann sollte sich der igor-daemon nicht mehr sofort beenden, sondern weiterlaufen. Dafür sorgt der Eintrag "cont_if_no_conns". Dann sollte sich das log etwa so aussehen:

1136369957.724581 NODE5:node_init
1136369957.763854 CONN5:connection with fd 4 changed state from EMPTY to LISTEN
1136369957.809394 CONN5:connection with fd 5 changed state from EMPTY to LISTEN
1136369957.834978 NODE5:bootstrap in progress
1136369958.075766 CONN5:connection with fd 6 changed state from EMPTY to OPENING
1136369958.103468 NODE5:node_init_done; ref: (d248d5aee12711df318b472ace6ce24044a2160c viac3.anlagen.local:11073), net_listen: viac3.anlagen.local:11073, client_listen: viac3.anlagen.local:11072
1136369958.103528 DFLT5:back to main, starting main loop
1136369958.197968 CONN5:connection with fd 6 changed state from OPENING to READY
1136369958.198605 NODE5:got a message of type Ping
1136369958.198686   ID5:id change from (--EMPTY-ID-- --EMPTY-TRANSPORT--) to (128fc712fad3f5a20bc5d255eb7b401f8ac00191 vdr.ibds.uka.de:11073)
1136369958.345745 NODE5:got a message of type RecommendLinks
1136369958.447786 NODE5:got a message of type WantNewLinks
1136369958.524724 NODE5:got a message of type RecommendLinks
1136369958.749217 NODE5:got a message of type WantNewLinks
1136369959.284502 NODE5:got a message of type Ping
[...]
1136369966.714448 NODE5:got a message of type RecommendLinks
1136369966.895995 NODE5:got a message of type WantNewLinks
1136369967.270957 NODE5:got a message of type RecommendLinks
1136369967.440881 NODE5:got a message of type WantNewLinks
1136369967.514335 NODE5:got a message of type Ping
1136369967.878282 NODE5:got a message of type WantNewLinks
1136369967.979657 NODE3:SIG 2 caught, shutting down
1136369967.979837  CBL4:select: Interrupted system call
1136369967.979849 NODE5:shutting down node
1136369967.979857 NODE5:dumping connection table
1136369967.979946 NODE5:conntable: otherend (128fc712fad3f5a20bc5d255eb7b401f8ac00191 vdr.ibds.uka.de:11073), connstate READY, fd 6
1136369967.979957 NODE5:dumping connection table finished
1136369967.980010 CONN5:connection with fd 4 changed state from LISTEN to CLOSED
1136369967.980020 CONN5:the just closed connection (fd 4) sent 0 bytes in 0 messages and received 0 bytes in 0 messages. 0/0 bytes are left for recv/send
1136369967.980048 CONN5:connection with fd 5 changed state from LISTEN to CLOSED
1136369967.980057 CONN5:the just closed connection (fd 5) sent 0 bytes in 0 messages and received 0 bytes in 0 messages. 0/0 bytes are left for recv/send
1136369967.980318 NODE5:closing connection with cbhandle 3 and wcbhandle 0
1136369967.980418 CONN5:connection with fd 6 changed state from READY to CLOSED
1136369967.980438 CONN5:the just closed connection (fd 6) sent 10092 bytes in 46 messages and received 10264 bytes in 44 messages. 759/0 bytes are left for recv/send
1136369967.980454 NODE5:node shutdown complete
1136369967.980461 NODE5:NODE stat: Sent 10092 bytes in 46 messages; Received 10264 bytes in 44 messages; Used 1 connections
1136369967.980475  CBL5:CBL statistics: average fds found 3.000000, average timers found 3.000000, average mintimer val 0.378055

Schreib mal, ob Du damit weiterkommst.

Ich scheitere momentan daran, daß sich der vdr beim Starten der Plugins (genauer: beim Starten des dvdrepg) verabschiedet... weiß da auch nicht weiter.

Grüße,
beemer

Zitat

Original von olafhenkel
Nehmen wir einmal an, natürlich rein hypothetisch, ich hätte irgendwelche Softpornos von mir und meiner (nichtexistentin) Freundin oder sonstwie irgendwelches Sex-, Hardcore-, Crime- oder Action-Material, dass auf anderen Festplatten nichts zu suchen hat. Wie verhindere ich hier, dass andere User an diese Aufnahmen herankommen ?!

Von videgor wird sowas gar nicht erst verteilt, denn dieses Material ist nicht via Uhrzeit@Kanal addressierbar.

Zitat

Kann man also bestimmte Festplattenbereiche komplett sperren bzw. wie kann man es ermöglichen, dass Aufnahmen in Teil- oder Komplettbereichen für das Peer-To-Peer-Netzwerk unzugänglich gemacht werden ?

Besser: man kann solche Bereiche gar nicht erst freigeben.

Zitat

Ferner, wenn wir schon dabei sind, Aufnahmen zu tauschen, wieso beschränkt sich das nur auf .vdr-Daten ? Letztendlich sind diese Dateien ja doch recht gross und wenn man bspw. Konvertierungen nach .avi, .ogg, .mpg oder anderen Containerdateiformaten macht, die einem nicht sooo viel Platz auf der Platte klauen, dann sollte man es doch möglich machen, auch an diese Daten heranzukommen, sofern der User sie den Mitusern zur Verfügung stellen will.

Das Ziel von videgor ist es, dass die Aufnahmen hinterher genau so aussehen wie lokal aufgenommen. Das Problem bei sharen von komprimierten Formaten ist, dass jeder die Daten etwas anders komprimiert und deshalb das Zusammenfuegen nicht mehr funktioniert. Bei videgor werden die .vdr-Dateien ausgetauscht, die sollten bei digitalen Aufnahmen bei allen Quellen gleich sein. Deshalb ist das Zusammenfuegen von Schnipseln einfach.

Zitat

Wie wird der Zugriff anderer, sensibler, persönlicher Dateien verhindert (Adressbücher, Mails, sonstiger Privat"scheiss") ?

Ich bin zwar kein Hochsicherheitsfanatiker, hab's aber nicht wirklich gern, wenn durch Sicherheitslücken irgendwie andere Leute auf meinem Rechner stöbern können.

wie oben schon erwaehnt, ist videgor nicht dafuer konzipiert, beliebige Dateien transportieren zu koennen. Nur Schnipsel von .vdr-Dateien (sowie Scheduler-Informationen und EPG-Daten) werden ausgetauscht.

Da wir aber nicht perfekt sind, sind Programmierfehler moeglich (oder besser: sehr wahrscheinlich). Deswegen ist das ganze open-source: Jeder kann sich an der Fehlersuche/Beseitigung beteiligen.

Zitat

Ein letztes bezieht sich auf die Installationsroutine, in der von irgendwelchen Patches die Rede ist, die es da aufzuspielen gilt. Jetzt ist ja bspw. der Bigpatch zu einer aktuellen Institution geworden, die man nicht mehr missen möchte. Ist dieser "compliant" verträglich mit dem Bigpatch ? Derzeit für VDR 1.3.37.

Klaus Schmidinger hat Teile von unseren Patches in den VDR uebernommen, sodass bei naechsten videgor-Release das Patchen wahrscheinlich weniger wird.

Kendy

[quote]Original von thorsten.gehrig
Beim Igor selbst habe ich auch "probleme": wenn ich igor aufrufe passiert *nichts*.
[quote]

Nichts ist natuerlich ein wenig wenig.

Steht danach etwas in igor.log?
Wenn nicht, was passiert wenn man vor den Aufruf von igor noch 'strace ' schreibt?

Kendy