Systemd unit file: Can/Should ExecStart and ExecStop run a script?

[Toshio Kuratomi]

On Wed, Oct 19, 2011 at 06:53:12PM -0500, Richard Shaw wrote:
> On Wed, Oct 19, 2011 at 6:34 PM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
> > On Wed, 19.10.11 18:28, Richard Shaw (hobbes1069 at 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!
> 
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.

On top of that, if I've been following the thread right, the previous rpm
ran as a mythbackend user -- so it's only people who customized away from
that to a root user that will have this migration issue, correct?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111021/9c8641dd/attachment.bin