VDR Portal

Videoverzeichnis: /media ist für einhängepunkte vorgesehen, also das eher nicht. In Abhängigkeit davon wie du die Aufnahmen betrachtest, kommt /var/lib/vdr oder /srv/vdr/ in Betracht. yaVDR benutzt z.B. letzteres ("In diesem Verzeichnis sollen die Daten zu angebotenen Diensten abgelegt werden."), Für /var/lib/ : "State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. State information should generally remain valid after a reboot, should not be logging output, and should not be spooled data. "

Ansonsten ist das was du geschrieben hast in etwa das was Debian macht (die versuchen die FHS einzuhalten).

epg.data ist in /var/cache/vdr
plugins &Co in /usr/lib/vdr/
Architektur-unspezifische Sachen in /usr/share/vdr
channels.conf &Co in /var/lib/vdr/

Der VDR sieht ja vor das die Plugin Konfigverzeichnisse im Plugins Verzeichnis des VDR Konfig Verzeichnisses liegen sollen (Leider halten sich nicht alle Plugins daran).
Die Debian Distributionen Patchen die Plugin Konfigverzeichnisse generell nach /var/lib.

Beides ist AFAIK falsch und IMHO blödsinnig.

Es gibt ja drei Arten von Daten in diesen Verzeichnis.
1. Resourcen (Bilder usw.)
2. Konfigfiles (die man auf der Konsole editiert).
3. Datenbankendateien (alles was man per GUI Editiert oder was sich automatisch ändert).

Also eigentlich (wenns mans wirklich nahc FHS machen will) müssten die Resourcen nach /usr/lib/... (oder /usr/share/...?), die Konfigfiles nach /etc/... und die Datenbankendateien nach /var/...


BTW: Ich mache es so...
Alle Plugins sind so gepatcht das sie ihre Daten in ConfigDirectory(PLUGINNAME_i18n) suchen/erwarten.
Die Dist Defaults liegen unter /usr/share/vdr/base-config und meine persönlichen Defaults liegen unter /usr/share/vdr/site-config. Beides kommt aus DEB Paketen und mischt Resouchen und Konfigfiles.
Und die Datenbankendateien (also auch das was man wirklich backupen muss) liegen unter /home/<vdruser>/.vdr

Das wird dann per AUFS unter /dev/shm/.vdr/<vdruser>/config zusammengemountet.

Ist zwar auch falsch, aber wenigsten sauber getrennt und übersichtlich. Insbesondere wenn man ans tägliche Backup denkt.

cu

Quoted from "Copperhead"

Warum allerdings soll die channels.conf nach /var/lib/vdr? Ist das keine Konfigurationsdatei, die ehr nach /etc/vdr passen würde?

Nein, Konfigurationdateien in /etc sind wirklich Konfigurationsdateien die vom Admin manuell bearbeitet (und z.B. bei Debian beim Paketupdate evtl. automatisch ersetzt werden) werden. Die channels.conf ist ne Datenbank die nach /var/lib/... gehört.

cu

Quoted from "Copperhead"

Dumm ist aber, dass der VDR es gar nicht erlaubt diese Dateien unterschiedlich abzulegen und die Plugins erst recht nicht

Deswegen sind die unter Debian und Ubuntu/yaVDR auch größtenteils zwischen /etc/vdr/ und /var/lib/vdr durch Symlinks verbunden.

Ich habe es derzeit so:
VDR-Configs: /etc/vdr

Plugins: /usr/lib/vdr/plugins
Aufnahmen: /video0

Ich baue aber gerade ein neues System (hjslfs mit aktuellem LFS-SVN-Buch) da werden dann die Aufnahmen verschoben nach /srv/vdr/video0
Die Daten unter /etc/vdr werde ich aber erstmal so lassen, das wild zwischen /etc/vdr und /var/lib/vdr hin und her zu linken gefällt mir nicht wirklich.

Edit: Mir kam gerade noch die Idee was kls davon hält. Dann könnte man ihm ja einen Patch bauen der die Dateien sauber trennt, jeweils eine option für die beiden Verzeichnisse bietet (alternativ über Make.config festlegen). Die Plugins bekommen in der API eine neue Option spendiert womit sie das neue Verzeichnis abfragen können, dann kann man die Plugins auch sauber und einfach anpassen. Wer alles so haben will wie bisher setzt halt einfach beide Verzeichnisse auf den gleichen Namen.

Quoted from "Maniac"

Edit: Mir kam gerade noch die Idee was kls davon hält.

Ich habe noch nie allzu viel davon gehalten, die Dateien einer Applikation quer über das gesamte Filesystem zu verstreuen ;-)

Klaus

Ok

Hätte den so ein Patch, wenn er vernünftig gebaut ist, die Chance in den VDR zu kommen?
Als default würde ich dann setzen das alles so bleibt wie der VDR es derzeit macht. Die User/Distributionen können über einen weiteren Parameter oder die Make.config dieses Verhalten dann ändern. Plugins würden die Möglichkeit bekommen das neue Verzeichnis über eine ähnliche Funktion wie cPlugin::ConfigDirectory() abfragen und dann nutzen.

Meiner Meinung macht so ein Patch nämlich nur Sinn, wenn er dann direkt im VDR vorhanden ist. Dadurch wäre dann für die Plugin-Autoren eine Schnittstelle geschaffen um die Plugins auch entsprechend anzupassen.

Quoted from "Maniac"

Ok :)

Hätte den so ein Patch, wenn er vernünftig gebaut ist, die Chance in den VDR zu kommen?
Als default würde ich dann setzen das alles so bleibt wie der VDR es derzeit macht. Die User/Distributionen können über einen weiteren Parameter oder die Make.config dieses Verhalten dann ändern. Plugins würden die Möglichkeit bekommen das neue Verzeichnis über eine ähnliche Funktion wie cPlugin::ConfigDirectory() abfragen und dann nutzen.

Wenn's denn bei einem weiteren Directory bleibt ;-)

So wie ich das sehe, gibt es bei N Usern N+1 Meinungen, welche Datei wo hin gehört.
Ich halte nichts davon, das alles so kompliziert zu machen.
Es gibt das große Video-Directory für die Aufnahmen, und es gibt ein Konfigurationsdirectory. Mehr ist meiner Meinung nach für eine so konkrete Applikation wie VDR nicht nötig.
Wenn ich dem Thema weiter nachgebe, dann wird ziemlich sicher eine ewige DIskussion darüber beginnen, welche Datei denn nun von welchem Typ ist und daher hier, oder besser dort, oder vielleicht ganz woanders sein sollte (genau genommen läuft diese Diskussion ja schon, wie weiter vorne in diesem Thread zu sehen ist). Und irgendwann weiß keiner mehr, wo er denn nach einer bestimmten Datei suchen soll.
Ich mag's am liebsten einfach...

Klaus

Hallo Leute,

auch wenn ich als Linux-(Fast)-Anfänger zur Theorie wenig sagen kann,
habe ich doch lange Benutzer zentriertes Design gemacht,
und aus dem Blickwinkel kann ich KLS nur zustimmen.

Einfach ist einfach besser ;-))

Mir zum Beispiel ist nie klar geworden warum es /var/lib/vdr
und /etc/vdr braucht, ist aus meiner (User-)Sicht beides Konfiguration...
Gut ist beim VDR, dass das verlinkt ist, das macht es wieder einfacher.
Von mir aus könnte einfach /etc/vdr nach /var/lib/vdr gelinkt sein, fertig.

Just my view,

Günter

Quoted from "beachboy"

Mir zum Beispiel ist nie klar geworden warum es /var/lib/vdr
und /etc/vdr braucht, ist aus meiner (User-)Sicht beides Konfiguration...

Naja, knapp 40 MB Daten im Konfigverzeichnis eines Programmes (bei meiner Installation so ganz real) ist schon irgendwie schräg Vorallem weil das Meiste davon Bitmaps, Fonts und irgendwelche Datenbanken sind.
Hat schon seinen Sinn Binäre Resourcen aus Konfigurationverzeichnissen rauszuhalten.

cu

Moin,

ich finde, dass in dieser Diskussion öfters Äpfel mit Birnen verglichen werden.
Der VDR ist (auf den Maschinen, wo er das Starten und Beenden kontrolliert) streng genommen keine Benutzer-Anwendung, deshalb sollte er auch nicht mit solchen verglichen werden. Der VDR ist eher wie eine System-Anwendung zu sehen, also eher wie ein Datenbank-System, o.ä.

Bei der Characterisierung der Daten zählt nicht bloß die Tatsache, ob es Konfigurationsdaten sind oder nicht, sondern auch, ob die Anwendung die Daten verändert.
/etc - sollte als RO-Bereich für Anwendungen angesehen werden. In vielen (professionellen) Umgebungen wird der Bereich readonly gemountet und nur bei Admin-Tätigkeiten bindet der die Platte zusätzlich (woanders) im Schreibmodus ein.
MySQL z.B. hält sich auch eine eigene Datenbank, um Systeminformationen abzulegen - aber die liegt selbstverständlich unter /var

Andererseits gibt es auch "professionelle" Anwendungen, die sich einen feuchten um FHS kümmern.
Wer schon mal Oracle unter Linux installiert hat, ist nicht selten wie vom Donner gerührt, wenn plötzlich die Datenbank unter /usr/lib liegt.

Im Sinne von Klaus wäre /opt der richtige Ort, um den VDR zu installieren. Dort kann es z.B. auch ein etc Verzeichnis geben - was auch immer die Anwendung will.
Wenn ich mir eine debian-Installation von VDR anschaue, gehört "eigentlich" nur /etc/default/vdr wirklich nach /etc

Gruß Gero

Quoted from "Maniac"

Edit: Mir kam gerade noch die Idee was kls davon hält. Dann könnte man ihm ja einen Patch bauen der die Dateien sauber trennt, jeweils eine option für die beiden Verzeichnisse bietet (alternativ über Make.config festlegen). Die Plugins bekommen in der API eine neue Option spendiert womit sie das neue Verzeichnis abfragen können, dann kann man die Plugins auch sauber und einfach anpassen. Wer alles so haben will wie bisher setzt halt einfach beide Verzeichnisse auf den gleichen Namen.

Worum genau geht es hier? Was mir schon länger ein Dorn im Auge ist, ist die Tatsache, dass Plugins auch ihre Resourcen aus ihrem "Config Directory" lesen wollen. Das ist einfach der Tatsache geschuldet, dass Plugins nur das Config Directory einfach via API-Funktion ermitteln können. Ich möchte aber Resourcen und echte Config gerne trennen.

Alles was das Plugin ändern können muss (echte "Konfigurationseinstellungen") möchte ich, wie gehabt, unter /etc/vdr/plugins/PLUGINNAME ablegen. Owner ist VDR-User --> Plugin, bzw. VDR kann schreiben.

Alles was das Plugin nur lesen können muss (Resourcen) möchte ich unter /usr/share/vdr/PLUGINNAME haben. Hier darf "root" der "Owner" sein und der VDR-User braucht kein Schreibrecht.

Wenn das das ist, was du auch umsetzen willst, dann wäre ich auch extrem an der Umsetzung interessiert! Das Verzeichnis darf auch gerne standardmäßig mit dem ConfigDirectory übereinstimmen, sollte aber über Make.config dann anpassbar sein. Mein Vorschlag:



Wenn Hilfe benötigt wird (z.B. um das dann in der PLUGINS.html zu dokumentieren) helfe ich gerne aus.

Quoted from "geronimo"

Bei der Characterisierung der Daten zählt nicht bloß die Tatsache, ob es Konfigurationsdaten sind oder nicht, sondern auch, ob die Anwendung die Daten verändert.
/etc - sollte als RO-Bereich für Anwendungen angesehen werden. In vielen (professionellen) Umgebungen wird der Bereich readonly gemountet und nur bei Admin-Tätigkeiten bindet der die Platte zusätzlich (woanders) im Schreibmodus ein.

Da weichen aber auch andere von ab. Ich würde da mal CUPS als Beispiel anführen. Auch der schreibt seine Konfiguration dynamisch, wenn man via Webinterface oder über die CLI-Tools konfiguriert.

Soweit würde ich den VDR jetzt garnicht zerreißen wollen. Klar ist die channels.conf eigentlich eine recht dynamische Datei, aber letztlich ist es eben immer noch eine Konfigurationsdatei, und als solche ist sie unter /etc zumindest nicht ganz falsch. Ist letztlich auch Konfigurationssache. Wenn ich dem VDR verbiete, neue Channels zu erkennen, dann kann ich die channels.conf durchaus auch manuell verwalten und auch Readonly mounten sollte dann keine negativen Folgen haben.

Quoted

Da weichen aber auch andere von ab. Ich würde da mal CUPS als Beispiel anführen. Auch der schreibt seine Konfiguration dynamisch, wenn man via Webinterface oder über die CLI-Tools konfiguriert.

Lach - auch wieder ein Thema, bei dem sich herrlich die Haare spalten lassen
Für mich schreibt in dem Beispiel nicht CUPS selbst, sondern eine Admin-Anwendung (webmin macht derlei ja auch)

Quoted

Wenn ich dem VDR verbiete, neue Channels zu erkennen, dann kann ich die channels.conf durchaus auch manuell verwalten und auch Readonly mounten sollte dann keine negativen Folgen haben.

Da bin ich mal wieder völlig falsch angekommen
Es geht überhaupt nicht darum, dem VDR irgend etwas zu verbieten (so weit kommts noch ), sondern lediglich darum, wer wo schreiben darf.
Die setup.conf wird ja auch regelmäßig vom VDR geschrieben, ist also meiner Ansicht nach auch keine Konfigurationsdatei, sondern eine (Text-)Datenbank.
So wie ich FHS interpretiere, sollten /etc und /usr für Anwendungen als readonly gelten.

Es gibt viele Beispiele, wo Anwendungen systemweite Grundeinstellungen haben und Anwender Einstellungen ändern können.
Wenn die Anwendung für Linux richtig entworfen wurde, werden die systemweiten Grundeinstellungen von /etc gelesen und die benutzerabhängigen Einstellungsänderungen unter ~/.<Anwendungsname>/was-auch-immer gespeichert.

Auf die Weise kann ein Admin für vernünftige Vorgabewerte sorgen und der Anwender kann es trotzdem für sich anpassen.
Das System ist sauber und keiner pfuscht beim anderen rum.

Ich denke, man muss schon unterscheiden, was das für ein Rechner ist und welche Rolle VDR dabei spielt.

Mein Backend beispielsweise wird vom VDR kontrolliert - also ist der VDR eine System-Anwendung.
Bei meinem Frontend verwende ich den VDR zum Schneiden und Index neu erstellen. Hier ist der VDR ganz klar eine Benutzer-Anwendung, die nichts im System "rumpfuschen" darf. Deshalb sind dort die Berechtigungen auch nicht VDR kompatibel.
Als Client-Anwendung verwende ich vdr-sxfe, welches mir nur ein "Fenster" zu dem Backend-VDR öffnet. Der VDR hat für mich auf dem Client (== Desktop) nichts verloren, deshalb gibt es weder Kanallisten, noch EPG-Daten, noch Aufnahmen am Desktop.
Aber das ist meine Ansicht - die muss niemand teilen

Gruß Gero

Moin!

Als ich den Threadtitel las, wusste ich, dass es mal wieder "los geht", das Thema kommt ja häufiger mal... :-)

Meine Meinung:
Da man im Prinzip alle conf-Dateien des vdr über die Oberfläche des vdr verändern kann, muss der vdr sie schreiben können. Deshalb sollten sie unter /var/lib/vdr liegen.
Die Diskussion darüber, ob einige statisch oder dynamisch sind (scr.conf, diseqc.conf), führt zu nichts, denn das ist bei jedem anders und hängt vom Einsatzgebiet des vdrs ab. Ein rein analoger (pvrinput-)vdr braucht z.B. nie die channels.conf anpassen, ein DVB-vdr aber schon, um zumindest die PIDs ab und an anzupassen.
Außerdem jedes mal zu überlegen, wo denn nun welche Datei liegt, ist mir zu "blöde". Wenn alle unter /var/lib/vdr liegen, ist das Backup dieser Dateien auch wesentlich einfacher.

Das binäre Resourcen am besten woanders aufgehoben sind, ist sicherlich noch am verständlichsten. Das wäre die einzige Änderung, der ich zustimmen würde.

Lars.

Quoted

Da man im Prinzip alle conf-Dateien des vdr über die Oberfläche des vdr verändern kann, muss der vdr sie schreiben können. Deshalb sollten sie unter /var/lib/vdr liegen.

Völlig Deiner Meinung!

Wenn ich es richtig verstanden habe, werden die statischen Einstellungen ja via Befehlszeilen-Optionen behandelt (also das, was - bei debian - über /etc/default/vdr angepasst werden kann), der Rest ist dynamisch. Deshalb schrieb ich ja schon, dass /etc/default/vdr für mich die einzige Konfigurations-Datei im Sinne von FHS ist.

Quoted

Das binäre Resourcen am besten woanders aufgehoben sind, ist sicherlich noch am verständlichsten

Auch hier halte ich den Debian-Weg für perfekt:
Daten die von mehreren verwendet werden (z.B. Symbole der Sender) kämen nach /usr/share/vdr/...
Daten, die vom Eigentümer als privat betrachtet werden (z.B. Bilder eines Skins o.ä.) kämen nach /usr/lib/vdr/...

Gruß Gero