You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

  • "Copperhead" started this thread

Posts: 4,693

Location: Main-Spessart

  • Send private message

1

Monday, February 6th 2012, 5:00pm

VDR-Verzeichnisse nach Filesystem Hierarchy Standard (FHS) richtig ablegen?!?

Hi,

mancher denkt jetzt vielleicht was das soll, aber mich würde mal interessieren, wie ihr die FHS auslegt.

http://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Ich sehe das im Moment so:
VDR-Configs: /etc/vdr
Plugins: /usr/lib/vdr (eventuell auch /usr/lib/vdr/plugins)
Videoverzeichnis: Wenn ich die FHS richtig lese sollte das /media/recordings o.ä. sein.

Zusätzlich müsste die epg.data Datei noch in /var/cache/ gespeichert werden.

Was denkt ihr dazu?

Ich will mit diese Disskussion nichts durchsetzen oder so, ich habe einfach nur Interesse an eurer Auslegung.

Gruß

Copperhead
VDR4Arch-Next --> Lian-Li PC-C37B | Gigabyte GA-MA78LMT-US2H | AMD Athlon II X2 250 | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

2

Monday, February 6th 2012, 5:25pm

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/
VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

3

Monday, February 6th 2012, 5:50pm

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

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

  • "Copperhead" started this thread

Posts: 4,693

Location: Main-Spessart

  • Send private message

4

Monday, February 6th 2012, 6:01pm

Also hat yaVDR dann im Vollen: /srv/vdr/video0 und dann bei jeder weiteren Platte /srv/vdr/video1 ...?

Warum allerdings soll die channels.conf nach /var/lib/vdr? Ist das keine Konfigurationsdatei, die ehr nach /etc/vdr passen würde?
VDR4Arch-Next --> Lian-Li PC-C37B | Gigabyte GA-MA78LMT-US2H | AMD Athlon II X2 250 | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

5

Monday, February 6th 2012, 6:03pm

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

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

  • "Copperhead" started this thread

Posts: 4,693

Location: Main-Spessart

  • Send private message

6

Monday, February 6th 2012, 6:29pm

Hmm, dann sind aber remote.conf und setup.conf auch Datenbanken.
diseqc.conf und scr.conf sind allerdings keine.

Das ist ganz schön kompiliziert. Dumm ist aber, dass der VDR es gar nicht erlaubt diese Dateien unterschiedlich abzulegen und die Plugins erst recht nicht.
VDR4Arch-Next --> Lian-Li PC-C37B | Gigabyte GA-MA78LMT-US2H | AMD Athlon II X2 250 | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

7

Monday, February 6th 2012, 6:46pm

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.
yaVDR-Doku

Meine VDRs

VDR 1: Point of View Ion-330-1 (Intel Atom 330@1,6 GHz). 2GB, 2TB HDD, KNC One DVB-C, Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, yaVDR 0.5 testing
VDR 2: Acer Revo 3610, 4GB Ram, 1x HDD 320 GB, Pinnacle PCTV SAT 452e, Medion X10, YaVDR 0.5
VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce 210 512 MB, 500 GB, DD Duo-flex CT, Arch LInux, VDR 2.1.6, CIR-Empfänger
Client 1: Raspberry Pi Model B, Arch Linux ARM, VDR 2.1.6
Ceterum censeo enchiridia esse lectitanda.

8

Monday, February 6th 2012, 6:46pm

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ls -l /var/lib/vdr 
insgesamt 92
-rw-rw-r-- 1 vdr vdr 50600 2012-01-14 05:58 channels.conf
-rw-r--r-- 1 vdr vdr  8181 2011-07-03 20:49 channels.conf.cable
-rw-r--r-- 1 vdr vdr 13935 2011-07-03 20:49 channels.conf.terr
lrwxrwxrwx 1 vdr vdr    29 2011-12-29 10:45 commands.conf -> ../../cache/vdr/commands.conf
lrwxrwxrwx 1 vdr vdr    20 2011-12-29 10:45 diseqc.conf -> /etc/vdr/diseqc.conf
lrwxrwxrwx 1 vdr vdr    23 2011-12-29 10:45 keymacros.conf -> /etc/vdr/keymacros.conf
drwxr-xr-x 3 vdr vdr  4096 2011-12-24 22:42 plugins
lrwxrwxrwx 1 vdr vdr    28 2011-12-29 10:45 reccmds.conf -> ../../cache/vdr/reccmds.conf
-rw-r--r-- 1 vdr vdr  3818 2011-07-03 21:32 remote.conf
lrwxrwxrwx 1 vdr vdr    17 2011-12-29 10:45 scr.conf -> /etc/vdr/scr.conf
-rw-r--r-- 1 vdr vdr  2842 2012-01-14 06:50 setup.conf
lrwxrwxrwx 1 vdr vdr    21 2011-12-29 10:45 sources.conf -> /etc/vdr/sources.conf
lrwxrwxrwx 1 vdr vdr    24 2011-12-29 10:45 svdrphosts.conf -> /etc/vdr/svdrphosts.conf
drwxr-xr-x 2 vdr vdr  4096 2011-12-30 19:48 themes
-rw-r--r-- 1 vdr vdr     0 2011-12-25 10:50 timers.conf



Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ls -l /etc/vdr 
insgesamt 44
lrwxrwxrwx 1 root root   26 2011-12-29 10:45 channels.conf -> /var/lib/vdr/channels.conf
drwxr-xr-x 2 root root 4096 2011-12-30 19:48 command-hooks
-rw-r--r-- 1 vdr  vdr  3265 2011-09-10 14:41 diseqc.conf
-rw-r--r-- 1 vdr  vdr   210 2006-01-05 16:41 keymacros.conf
drwxr-xr-x 3 root root 4096 2012-02-02 13:11 plugins
drwxr-xr-x 2 root root 4096 2011-12-30 19:48 recording-hooks
lrwxrwxrwx 1 root root   24 2011-12-29 10:45 remote.conf -> /var/lib/vdr/remote.conf
-rw-r--r-- 1 vdr  vdr   509 2011-09-17 14:58 scr.conf
lrwxrwxrwx 1 root root   23 2011-12-29 10:45 setup.conf -> /var/lib/vdr/setup.conf
drwxr-xr-x 2 root root 4096 2011-12-30 19:48 shutdown-hooks
-rw-r--r-- 1 vdr  vdr  3839 2011-09-11 16:26 sources.conf
-rw-r--r-- 1 vdr  vdr   439 2011-07-03 21:13 svdrphosts.conf
-rw-r--r-- 1 vdr  vdr   261 2011-08-27 21:36 unicable.conf
lrwxrwxrwx 1 root root   14 2011-12-29 10:45 vdr.default -> ../default/vdr
-rw-r--r-- 1 root root  290 2011-05-02 19:09 vdr.groups

9

Monday, February 6th 2012, 7:45pm

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.

This post has been edited 1 times, last edit by "Maniac" (Feb 6th 2012, 7:51pm)


kls

Master

Posts: 2,629

Location: Mettenheim

  • Send private message

10

Monday, February 6th 2012, 10:22pm


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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer

11

Monday, February 6th 2012, 10:41pm

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.

kls

Master

Posts: 2,629

Location: Mettenheim

  • Send private message

12

Monday, February 6th 2012, 11:04pm

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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer

beachboy

Professional

Posts: 762

Location: Bodensee

  • Send private message

13

Monday, February 6th 2012, 11:16pm

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

Aktuell: Projekt HD-VDR abgeschlossen:
:tup Ubuntu 12.04; Kernel 3.2.0-34; mit Parallelbetrieb von:
:tup VDR 1.7.27 über S2-6400 (HDMI1)
:tup XBMC Eden über GT520 (HDMI2)
:tup Beides an Sony KDL-55EX725
:tup Harmony zum Umschalten zwischen VDR und XBMC
:tup MusicPD Steuerung per iPOD ist perfekt


14

Tuesday, February 7th 2012, 12:29am

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

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

15

Tuesday, February 7th 2012, 6:42am

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

16

Tuesday, February 7th 2012, 7:39am


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:

Source code

1
const char *ResourceDirectory(const char *PluginName = NULL);


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

17

Tuesday, February 7th 2012, 7:43am


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.

18

Tuesday, February 7th 2012, 9:28am

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 :O
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

mini73

Moderator

Posts: 5,082

Location: Flensburg

  • Send private message

19

Tuesday, February 7th 2012, 10:06am

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

20

Tuesday, February 7th 2012, 11:06am

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

Similar threads