It looks like I'll be taking over mythtv packaging for RPM Fusion and I noticed it still only uses a sysv init script. In the sysv script it sets some ACL permissions on video and audio devices necessary for the backend service, and then on shutdown changes it back. I don't see any way to accomplish this in a systemd unit file other than running a script. What's the right way to do this? I have a template unit file (not meant to "work" yet): [Unit] Description=MythTV backend service After=mysqld.service [Service] Type=forking PIDFile=/var/run/mythbackend.pid ExecStart=/bin/sh /usr/libexec/mythtv/startmythbackend.sh ExecStop=/bin/sh /usr/libexec/mythtv/stopmythbackend.sh [Install] WantedBy=multi-user.target

This is what I wrote a while back for mythtv in rpmfusion but never submitted since I could not find someone to test it. Note this got picked up by someone and adapted to atrpm version the other day. Cant recall if that indvidual pinged me on irc or on some mailing list. #cat mythbackend.service [Unit] Description=MythTV Backend After=syslog.target network.target mysqld.service

[Service] Type=forking PIDFile=/run/mythbackend.pid Environment=MYTHCONFDIR=/etc/mythtv Environment=HOME=/etc/mythtv

ExecStart=/usr/bin/mythbackend --daemon --logfile /var/log/mythtv/mythbackend.log --pidfile /run/mythbackend.pid StandardError=syslog

On 10/19/2011 08:29 PM, Lennart Poettering wrote: > The After=syslog.target is unnecessary these days and should be removed > to keep things simple. If you expect upstream to ship unit files then you must realize  that upstream needs to ship a unit file that works across distribution on what ever systemd release downstream is using hence removing options that are no longer necessary X release of systemd is not an option.

You should manage acess control of device nodes from udev rules. That's the only reasonably safe way to handle these things. And this should not be mentioned at all in systemd unit files.

On 19/10/11 21:48, Richard Shaw wrote: > > On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering > <mzerqung(a)0pointer.de&gt;  wrote: >> >> You should manage acess control of device nodes from udev rules. That's >> the only reasonably safe way to handle these things. And this should not >> be mentioned at all in systemd unit files.

On Wed, Oct 19, 2011 at 23:20, Richard Shaw&lt;hobbes1069(a)gmail.com&gt; wrote: > Ok based on Tom's file I came up with the following. I know Lennart, > you don't like setting ACL's from Systemd, but unless someone want's > to help me write udev rules that will run before the start of > mythbackend and after it's stopped, this is all I have: Yeah, that looks very wrong. Like mentioned earlier in this thread, just put the user into the audio/video system group and forget about any permissions management.

On Wed, Oct 19, 2011 at 23:20, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote: > On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes <tom(a)compton.nu&gt; wrote: >> On 19/10/11 21:48, Richard Shaw wrote: >>> >>> On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering >>> <mzerqung(a)0pointer.de&gt;  wrote: >>>> >>>> You should manage acess control of device nodes from udev rules. That's >>>> the only reasonably safe way to handle these things. And this should not >>>> be mentioned at all in systemd unit files. > > Ok based on Tom's file I came up with the following. I know Lennart, > you don't like setting ACL's from Systemd, but unless someone want's > to help me write udev rules that will run before the start of > mythbackend and after it's stopped, this is all I have: Yeah, that looks very wrong. Like mentioned earlier in this thread, just put the user into the audio/video system group and forget about any permissions management.

I'd think best practice here would be for mythbackend package to create a mythbackend user which is a member of audio and video groups, and have the startup script run mythbackend as that user...would there be any problem with that approach?

On Wed, Oct 19, 2011 at 23:35, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote: > That works for me. I wonder if I could use ExecStartPre to run a shell > script to make sure the user is in those groups and write to stderr if > not? That's a job for a %pre RPM script, not a service. Create the user and put the user in the group when the package is installed.

> Also, the shell expansion doesn't work on ExecStart, so how to I set > the user in the command line? Hardcode it. It does not make much sense to configure something, or use config file indirections for stuff that does not need to be changed anyway.

That will work for the user, however, I was also going to allow for additional options from the sysconfig file, but $OPTIONS wasn't being expand either.

On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes <tom(a)compton.nu&gt; wrote: > On 19/10/11 21:48, Richard Shaw wrote: >> >> On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering >> <mzerqung(a)0pointer.de&gt;  wrote: >>> >>> You should manage acess control of device nodes from udev rules. That's >>> the only reasonably safe way to handle these things. And this should not >>> be mentioned at all in systemd unit files. Ok based on Tom's file I came up with the following. I know Lennart, you don't like setting ACL's from Systemd, but unless someone want's to help me write udev rules that will run before the start of mythbackend and after it's stopped, this is all I have: [Unit] Description=MythTV backend service After=network.target mysqld.service [Service] Type=forking PIDFile=/var/run/mythbackend.pid Environment=MYTHCONFDIR=/etc/mythtv Environment=HOME=/etc/mythtv Environment=MYTHBACKEND_USER=root EnvironmentFile=-/etc/sysconfig/mythbackend ExecStartPre=setfacl -m u:${MYTHBACKEND_USER}:x -R /dev/snd /dev/dvb /dev/video* /dev/vbi* ExecStart=/usr/bin/mythbackend --daemon --user $MYTHBACKEND_USER --logfile /var/log/mythtv/mythbackend.log --pidfile /var/run/mythbackend.pid $OPTIONS ExecStopPost=setfacl -x u:${MYTHBACKEND_USER} -R /dev/snd /dev/dvb /dev/video* /dev/vbi*

On Wed, Oct 19, 2011 at 5:09 PM, Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote: > On Wed, 19.10.11 16:20, Richard Shaw (hobbes1069(a)gmail.com) wrote: >> Ok based on Tom's file I came up with the following. I know Lennart, >> you don't like setting ACL's from Systemd, but unless someone want's >> to help me write udev rules that will run before the start of >> mythbackend and after it's stopped, this is all I have: >> >> [Unit] >> Description=MythTV backend service >> After=network.target mysqld.service >> >> [Service] >> Type=forking >> PIDFile=/var/run/mythbackend.pid >> Environment=MYTHCONFDIR=/etc/mythtv >> Environment=HOME=/etc/mythtv >> Environment=MYTHBACKEND_USER=root >> EnvironmentFile=-/etc/sysconfig/mythbackend >> ExecStartPre=setfacl -m u:${MYTHBACKEND_USER}:x -R /dev/snd /dev/dvb >> /dev/video* /dev/vbi* >> ExecStart=/usr/bin/mythbackend --daemon --user $MYTHBACKEND_USER >> --logfile /var/log/mythtv/mythbackend.log --pidfile >> /var/run/mythbackend.pid $OPTIONS >> ExecStopPost=setfacl -x u:${MYTHBACKEND_USER} -R /dev/snd /dev/dvb >> /dev/video* /dev/vbi* > > So, ignoring that access management should not be done with systemd, and > that as others already suggested it's much better to just add the > MYTHBACKEND_USER to the audio and video groups, and not make it > configurable (in fact MYTHCONFDIR shouldn't be configurable either. You > are just creating confusion with adding an option for that, not helping > anybody), these lines won't work, since systemd is not a shell and will > not expand the shell expressions /dev/video* and suchlike, and requires > absolute paths for the binary names. Well, as I had already mentioned I more or less relented, so I'm all for the a/v group method. My main concern is how to apply this. If someone has already been running mythbackend as root then all the recordings will be owned by root, in which case mythbackend will be unable to expire (delete) them. In order to fix this retroactively, I would have to do an sql query using the login credentials for mythbackend and pull the recording groups, then go to each recording group directory and chown all the recordings. That's a mess.

On Wed, Oct 19, 2011 at 6:34 PM, Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote: > On Wed, 19.10.11 18:28, Richard Shaw (hobbes1069(a)gmail.com) wrote: >> Well, as I had already mentioned I more or less relented, so I'm all >> for the a/v group method. My main concern is how to apply this. If >> someone has already been running mythbackend as root then all the >> recordings will be owned by root, in which case mythbackend will be >> unable to expire (delete) them. >> >> In order to fix this retroactively, I would have to do an sql query >> using the login credentials for mythbackend and pull the recording >> groups, then go to each recording group directory and chown all the >> recordings. That's a mess. > > Where are these recordings stored? Don't they have a common root > directory? Wouldn't a chown in that directory suffice? (it might be a > bit unfriendly to chown them away btw, adding an ACL for your user might > be a nicer solution) No, there's no common directory. The great thing about mythtv is it's flexibility, the bad thing about mythtv is it's flexibility. :) MythTV does not make any assumptions about the storage needs of the end user. It could be as simple as a Tivo equivalent, like myself, to someone storing stuff on a SAN, or multiple drivers/arrays/SAN's, etc. The storage directories paths are stored in the mythtv mysql database. You're right, an ACL approach may be better. But my sql-fu isn't really up to the task. For this to work: 1. mysqld would have to be running. 2. I would have to source /etc/mythtv/mysql.txt to get the variables (DBHostname, DBUserName, DBPassword, and DBName) 3. Call mysql from the commandline, query the DBName for the recording group path(s) 4. setfacl -m u:mythtv:rw -R /path1 /path2 /path3 /path[n]... And I'd have to do all this in a failsafe way from %pre without any user interaction... Ack!

On Wed, Oct 19, 2011 at 06:53:12PM -0500, Richard Shaw wrote: > You're right, an ACL approach may be better. But my sql-fu isn't > really up to the task. For this to work: > > 1. mysqld would have to be running. > 2. I would have to source /etc/mythtv/mysql.txt to get the variables > (DBHostname, DBUserName, DBPassword, and DBName) > 3. Call mysql from the commandline, query the DBName for the recording > group path(s) > 4. setfacl -m u:mythtv:rw -R /path1 /path2 /path3 /path[n]... > > And I'd have to do all this in a failsafe way from %pre without any > user interaction... > > Ack! > Don't do this.  You're breaking assumptions about what can be expected that an rpm is going to do when you go this far.  Suppose that an end user has explicitly changed the recordings from mythtv user to root.  This suddenly allows the mythtv backend user to access those files again.

The standard way to enable this would be to write a script or simply instructions and put it in the documenation directory.  Then blog, write in release notes (rpmfusion doesn't have release notes that I know of so....) etc about the migration issue and that users who want to can run the script or follow the instructions to get things converted.

Ok, reviving this conversation! I ran into the issue that user "mythtv" can not create the file "/var/run/mythbackend.pid". I see other services that have their pid file owned by their own user...

Also, user "mythtv" can't write to the log file in /var/log/mythtv/

In order to fix this retroactively, I would have to do an sql query using the login credentials for mythbackend and pull the recording groups, then go to each recording group directory and chown all the recordings. That's a mess.