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@xxxxxxxxxxx> wrote: > > On Wed, 19.10.11 18:28, Richard Shaw (hobbes1069@xxxxxxxxx) 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
Attachment:
pgpI3FZBMu7Ez.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
