[ANNOUNCE] Autostart Plugin 0.9.2

Hi Ulrich,

Vielen dank für diese Plugin! Das kommt gar gut aus für der VDR meiner Eltern
Leider geht es nicht mit mein 64 system:

make[1]: Map '/home/carel/src/vdr/vdr-1.7.20-zelf-gefroebeld-lb-war/PLUGINS/src/autostart-hg/detector' wordt verlaten
g++ -g -O3 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include       -shared -ldbus-1 -lpthread -lrt   -lcdio_cdda -lcdio -lm   -ldvdread   autostart.o mediadetectorthread.o configmenu.o detector.a  -o libvdr-autostart.so
/usr/bin/ld: detector.a(dbusdevkit.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
detector.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libvdr-autostart.so] Fout 1

Wird das schwierig oder sehr schwierig zu lösen?

Carel

War nicht schwierig

Im Makefile.inc:

-CXXFLAGS ?= -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses
+CXXFLAGS ?= -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC

Und das war es, das spielen fangt an!

Carel

Hi Ulrich

Jetzt start das plugin mit:

Aug 24 12:19:50 woonkamer vdr: [18568] initializing plugin: autostart (0.9.2): Start a plugin automatically
Aug 24 12:19:50 woonkamer vdr: Can not find key AUTOMOUNT
Aug 24 12:19:50 woonkamer vdr: UDisks found

Was ist das für eine Option, AUTOMOUNT?
Gibt's nicht im README oder Beispiele...

Txs, Carel

Für derjenigen die der VDR nicht unter root laufen lassen:

vi /usr/share/polkit-1/actions/org.freedesktop.udisks.policy
1,$s/no<\/allow/yes\<\/allow/g

Ich hab mal rücksichtslos alles auf yes eingestellt...

Cheers C

Der User "vdr" muss in die Gruppe "plugdev". Dann muss man auch an dem XML-Murks nichts rumbasteln.

Der User "vdr" muss in die Gruppe "plugdev".

Hatte ich versucht, funktioniert leider nicht...

VDR zwischendurch neugestartet? Der User "vdr" muss sich neu einloggen, dass die Berechtigungen wirken.

Ansonsten würde ich das als Bug einstufen. Am Desktop funktioniert das schließlich auch und da muss auch keiner was irgendwo umbauen.

Weils die Distribution schon erledigt hat - evtl muss eine policykit rule angelegt werden wenn sie nicht schon da ist. Oder der vdr muss innerhalb einer policykit session starten - kein Bug.

Du meinst so nen .pkms file ?

Ich glaube das da:
https://github.com/yavdr/yavdr…ty/50-local.d/10-vdr.conf

hat funktioniert. Alternativ müsste man das auch mit der Gruppe machen können oder etwas entsprechendes für die Gruppe ist schon vorhanden wie Mreimer vermutet hat.

Deine Regel sieht für mich sehr allgemein gehalten aus. Ich würde da befürchten, dass der VDR-User zu viele Rechte bekommt. Eigentlich soll er ja nur mounten können.

org.freedesktop.upower.*;org.freedesktop.consolekit.system.* kann man ja weglassen gegebenfalls (wenn es dann noch geht) - und man könnte sicher noch die einzelnen Optionen seperat erlauben (Einhängen, Aushängen) - sonst dürfte der vdr user wenn er udisk Funktionen benutzt evtl die Platte neu partitionieren - ich sehe da das Risiko eher gering

Wenn du einen besseren Vorschlag hast - Nur zu !

Mein besserer Vorschlag wäre es, rauszufinden, warum es mit "plugdev" nicht geht.

Irgendwas machen "KDE und Co", was das Autostart-Plugin nicht macht.

Leider blicke ich bei all diesem "modernen" Kram eher wenig durch. Mir ist das alles zu kryptisch. Müsste man wohl stundenlang Doku lesen um da durchzusteigen.

Eventuell bringt es was, wenn man mal eine passende Mailingliste sucht und die Entwickler fragt?

KDE&Co starten eine consolekit Session zusammen mit X -
Mit der Anmeldung wird die ConsoleKit Session gestartet und somit ist alles was in KDE/Gnome passiert auch in dieser Session und der User gilt als active, da:

<action id="org.freedesktop.udisks.filesystem-mount">
    <description>Mount a device</description>
    <description xml:lang="da">Montér en enhed</description>
    <description xml:lang="de">Gerät einhängen</description>
    <message>Authentication is required to mount the device</message>
    <message xml:lang="da">Autorisering er påkrævet for at montere et fil system</message>
    <message xml:lang="de">Zugriffsrechte werden benötigt um das Gerät einzuhängen</message>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

... das sagt, das aktive User das dürfen.

Niemand startet vdr aus X heraus.

Ein Blick in mein Desktop Ubuntu, bringt folgendes mit sich:

:/var/lib/polkit-1/localauthority# cat 10-vendor.d/com.ubuntu.desktop.pkla 
[Mounting, checking, etc. of internal drives]
Identity=unix-group:admin
Action=org.freedesktop.udisks.filesystem-*;org.freedesktop.udisks.drive-ata-smart*
ResultActive=yes

Das heisst auch wenn man nicht im X ist darf der Hauptuser in Ubuntu (der dann standardmässig in der admin Gruppe ist) die Festplatten über udisk ein und aushängen.

Ob man dort jetzt

Identity=unix-user:vdr    oder
Identity=unix-group:plugdev   oder
Identity=unix-group:admin

macht, bleibt doch gehupft wie gesprungen - Eigentlich keine ominöse plugdev-Magie die man erfragen muss.

Um das weiter zu spinnen könnte man nun fragen, was genau man tun muss, um die "Session", die der VDR eröffnet hat, via console-kit als "active" zu kennzeichnen.

AFAIK braucht es für console-kit weder X noch KDE oder Gnome. Es ist nur ein weiteres System, welches über DBUS gesteuert wird.

Damit die Session als aktive gilt, muss zwingend die Session innerhalb von X gestartet werden (ck-launch-session) . Sagte ich aber schon.

Umgekehrt. ck-launch-session wird verwendet um den Parent-Prozess der Session zu starten.

Hat mal wer "ck-launch-session /usr/bin/vdr" probiert? Also in der runvdr dieses "ck-launch-session" vor den VDR-Prozess pappen?

Allerdings stimme ich zu, dass der ganze Aufwand möglicherweise zu weit führt. Alternativ wäre eine *minimalistische* Konfiguration, um dem User "vdr", bzw. einer bestimmten Gruppe, die nötigen Rechte zuzusprechen, natürlich auch eine Lösung. Dann aber bitte so, dass wirklich *nur* das Recht für das Mounten gegeben wird. Der VDR-User muss keine Platten partitionieren können! Eine solche Config-Datei könnte dann z.B. mit den autostart-Plugin (Unterbereich "contrib") ausgeliefert werden. Wer es brauchen kann, kopiert es an die richtige Stelle.

Ok noch anders ck-launch-session muss in X gestartet werden damit er die consolekit session mit dem user als active startet - alles schon ausprobiert damals - du müsstest also warten mit dem vdr bis X da ist und vdr mit der ck session als parent prozess starten. Anyway die Diskussion fängt an mich zu nerven - wir sollten uns hier nicht an Begrifflickeiten längshangeln.

einfacher wäre das mit dem User oder der Gruppe,
Datei: /var/lib/polkit-1/localauthority/10-vendor.d/com.vdr.autostart.pkla

[Mounting, checking, etc. of internal drives]
Identity=unix-group:admin
Action=org.freedesktop.udisks.filesystem-mount;org.freedesktop.udisks.filesystem-mount-system-internal;org.freedesktop.udisks.filesystem-unmount-others
ResultActive=yes

Wenn das alles ist was gebraucht wird -> was zu prüfen wäre - ist jetzt aus dem Kopf mit Hilfe von Google geschrieben.

EOD